[SERVER-28103] ReplicationCoordinatorImpl::canAcceptWritesForDatabase() reads _canAcceptNonLocalWrites without proper locking Created: 24/Feb/17  Updated: 24/Mar/17  Resolved: 24/Feb/17

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

Type: Bug Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-27892 Clarify locking rules for _canAcceptN... Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

_mutex should be locked before reading _canAcceptNonLocalWrites.

https://github.com/mongodb/mongo/blob/14f16f384a2ace3b5ccb45dcbfbb66f3f57e945a/src/mongo/db/repl/replication_coordinator_impl.cpp#L1875

bool ReplicationCoordinatorImpl::canAcceptWritesForDatabase(StringData dbName) {
    // _canAcceptNonLocalWrites is always true for standalone nodes, always false for nodes
    // started with --slave, and adjusted based on primary+drain state in replica sets.
    //
    // That is, stand-alone nodes, non-slave nodes and drained replica set primaries can always
    // accept writes.  Similarly, writes are always permitted to the "local" database.  Finally,
    // in the event that a node is started with --slave and --master, we allow writes unless the
    // master/slave system has set the replAllDead flag.
    if (_canAcceptNonLocalWrites) {
        return true;
    }
    if (dbName == kLocalDB) {
        return true;
    }
    return !replAllDead && _settings.isMaster();
}



 Comments   
Comment by Spencer Brody (Inactive) [ 24/Feb/17 ]

Deferring thinking about the locking rules here until SERVER-27892

Comment by Eric Milkie [ 24/Feb/17 ]

I'm not sure. That variable is currently marked GX, which is:

// (GX) Readable under a global intent lock. Must either hold global lock in exclusive
// mode (MODE_X) or both hold global lock in shared mode (MODE_S) and hold _topoMutex
// to write.

That means that we are using database locks to protect readers from reading the variable at the same time as a writer, and that writers are protected against writing at the same time as another writer.

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