[SERVER-76822] Data race on LockRequest::lock between checking conflicting requests and cleaning unused locks Created: 03/May/23 Updated: 29/Oct/23 Resolved: 04/May/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0, 7.0.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Gregory Noma | Assignee: | Gregory Noma |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v7.0
|
||||||||
| Sprint: | Execution Team 2023-05-15 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 35 | ||||||||
| Description |
|
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. |
| Comments |
| Comment by Githook User [ 11/May/23 ] |
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: (cherry picked from commit 881020bf20b0c0dcf1ac949aa8d9e6b7f62bd0a9) |
| Comment by Githook User [ 04/May/23 ] |
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: |