[SERVER-28863] Coverity analysis defect 100734: Value not atomically updated Created: 19/Apr/17  Updated: 27/Oct/23  Resolved: 06/Oct/17

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

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: Backlog - Storage Execution Team
Resolution: Works as Designed Votes: 0
Labels: coverity
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

Non-atomic update of a concurrently shared value

Defect 100734 (STATIC_C)
Checker ATOMICITY (subcategory none)
File: /src/mongo/db/storage/kv/kv_storage_engine.cpp
Function mongo::KVStorageEngine::dropDatabase(mongo::OperationContext *, mongo::StringData)
/src/mongo/db/storage/kv/kv_storage_engine.cpp, line: 217
Locking "this->_dbsLock".

            stdx::lock_guard<stdx::mutex> lk(_dbsLock);

/src/mongo/db/storage/kv/kv_storage_engine.cpp, line: 221
Assigning data that might be protected by the lock to "entry".

            entry = it->second;

/src/mongo/db/storage/kv/kv_storage_engine.cpp, line: 222
Unlocking "lk._M_device". "entry" might now be unreliable because other threads can now change the data that it depends on.

        }

/src/mongo/db/storage/kv/kv_storage_engine.cpp, line: 243
Locking "this->_dbsLock" again.

            stdx::lock_guard<stdx::mutex> lk(_dbsLock);

/src/mongo/db/storage/kv/kv_storage_engine.cpp, line: 244
Using an unreliable value of "entry" inside the second locked section. If the data that "entry" depends on was changed by another thread, this use might be incorrect.

            opCtx->recoveryUnit()->registerChange(new RemoveDBChange(this, db, entry));



 Comments   
Comment by Eric Milkie [ 06/Oct/17 ]

This turns out to be okay because the DB lock outside this function prevents other code from removing any db's from _db while dropDatabase is running.

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