Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
2.3.2
-
None
Description
In various types of operations, the ClientCursor::ccmutex is acquired after the db mutex. For example, during a get more, a read lock on the db mutex is acquired, then the ccmutex is acquired to look up a ClientCursor with a particular cursor id.
Historically, a kill cursors ran by calling ClientCursor::erase() which acquired ClientCursor::ccmutex without a db mutex. (Any "in use" ClientCursor would be pinned and this function would fail before deleting it.)
Currently, kill cursors calls ClientCursor::eraseIfAuthorized(), which acquires the ClientCursor::ccmutex and then checks getAuthorizationManager()->checkAuthorization(). It looks like some code paths from checkAuthorization() may acquire a db lock to read user documents from a database's system.users collection - in particular in _probeForPrivilege … AuthExternalState::getPrivilegeDocument. I'm not familiar enough with the auth code to know under what circumstances these code paths will be triggered. However, if ccmutex can be acquired before the db mutex a deadlock is possible (as stated above most other operations acquire the db mutex then the ccmutex).
Could you let me know if I'm on the right tack with this?
Attachments
Issue Links
- is related to
-
SERVER-8389 Possible deadlock with auth check for building indexes
-
- Closed
-