[SERVER-38033] Collection _ns should be protected from concurrent operations Created: 08/Nov/18  Updated: 29/Oct/23  Resolved: 15/Nov/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.1.6

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: David Storch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-37443 Reuse in-memory catalog objects throu... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Query 2018-11-19
Participants:
Linked BF Score: 10

 Description   

Renames in the same database no longer swap Collection pointers in the UUIDCatalog. As soon as the rename sets a new NamespaceString on the collection, the entry in the UUID catalog changes, without having to take the UUIDCatlalog mutex. So even though the catalog is protected by a mutex, the _ns field on the Collection is not.

This means a lookup by UUID concurrent with a rename with a can potentially read the memory of a previous NamespaceString that has freed its underlying string.

The _ns field should be protected by a mutex for thread-safe read operations.



 Comments   
Comment by Githook User [ 15/Nov/18 ]

Author:

{'name': 'David Storch', 'email': 'david.storch@10gen.com', 'username': 'dstorch'}

Message: SERVER-38033 Fix CollectionImpl::_ns thread safety.
Branch: master
https://github.com/mongodb/mongo/commit/327cd8a01198efb2a18f6be6c4c614ef1fe25987

Generated at Thu Feb 08 04:47:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.