Data race on LockRequest::lock between checking conflicting requests and cleaning unused locks

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.1.0-rc0, 7.0.0-rc1
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • v7.0
    • Execution Team 2023-05-15
    • 35
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      In LockManager::hasConflictingRequests we read LockRequest::lock before getting the resource id and taking the bucket mutex. This can race with creating a new lock request when cleaning up unused locks.

      Once potential solution may be to change the interface for LockManager::hasConflictingRequests to take in the resource id, so that the bucket mutex can be locked right away.

              Assignee:
              Gregory Noma
              Reporter:
              Gregory Noma
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: