[SERVER-37552] Illegal concurrent access to KVDatabaseCatalogEntryBase::_collections Created: 10/Oct/18  Updated: 29/Oct/23  Resolved: 07/Apr/20

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

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

Issue Links:
Depends
depends on SERVER-33272 The DatabaseHolder::close() function ... Closed
depends on SERVER-39507 Remove Database::CollectionMap and us... Closed
Related
is related to SERVER-34531 listDatabases command can miss a data... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2020-04-06, Execution Team 2020-04-20
Participants:

 Description   

There is an apparent thread-safety error which can occur if a listDatabases command is running concurrently with a renameCollection command. This is closely related to the problem observed in SERVER-34531. As described in SERVER-34531, the listDatabases command takes a GlobalLock in MODE_IS. The renameCollection command acquires a GlobalLock in MODE_IX and a MODE_X database lock on the database on which it is performing the rename. Global locks of type IX and IS do not conflict, so the listDatabases command and renameCollection command are allowed to run concurrently.

The listDatabases command reads from KVDatabaseCatalogEntryBase::_collections, a std::map which is not thread-safe, in order to check whether the database is empty. At the same time, the renameCollection may be writing to the _collections map in order to represent the rename in the catalog data structures.

As far as I can tell, the fix for SERVER-34531 ensured that listDatabases would not fail to report a database due to a concurrent rename, but it did not prevent concurrent access to the _collections map.



 Comments   
Comment by Ian Whalen (Inactive) [ 12/Oct/18 ]

after the linked ticket is complete we can remove the concurrent access.

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