Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.9
-
None
-
None
Description
It seems that GridEncryptionManager uses metaStorageMux and checkpointReadLock in an inconsistent way.
Sometimes, the implementation acquires the mutex fist and then checkpointReadLock, sometimes vice versa, which may lead to a deadlock.
Let's consider the following scenario:
Thread-1: removeGroupKey acquired metaStorageMux and trying to get checkpointReadLock (cannot proceed further because of checkpointer)
Therad-2: doChangeMasterKey acquired checkpointReadLock and trying to get metaStorageMux (cannot proceed further due to thread-1)
Checkpointer-thread: trying to acquire the write lock (cannot get the lock due to thread-2)
Possible solutuion: acquire metaStorageMux before checkpointReadLock in doChangeMasterKey method
Attachments
Issue Links
- links to