Clean up lockorder data of destroyed mutexes #7846
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
Hopefully this fixes #7470. |
Member
|
Thanks! utACK if it fixes #7470. |
The lockorder potential deadlock detection works by remembering for each lock A that is acquired while holding another B the pair (A,B), and triggering a warning when (B,A) already exists in the table. A and B in the above text are represented by pointers to the CCriticalSection object that is acquired. This does mean however that we need to clean up the table entries that refer to any critical section which is destroyed, as it memory address can potentially be used for another unrelated lock in the future. Implement this clean up by remembering not only the pairs in forward direction, but also backward direction. This allows for fast iteration over all pairs that use a deleted CCriticalSection in either the first or the second position.
Member
Author
|
@laanwj Added a PR and commit description that explains the change and rationale. |
Contributor
|
Nice! LGTM. |
Member
|
@sipa OHH I get it now. |
laanwj
added a commit
that referenced
this pull request
Apr 14, 2016
5eeb913 Clean up lockorder data of destroyed mutexes (Pieter Wuille)
This was referenced Jan 23, 2017
thokon00
added a commit
to faircoin/faircoin
that referenced
this pull request
Mar 20, 2017
codablock
pushed a commit
to codablock/dash
that referenced
this pull request
Dec 20, 2017
5eeb913 Clean up lockorder data of destroyed mutexes (Pieter Wuille)
LarryRuane
pushed a commit
to LarryRuane/zcash
that referenced
this pull request
Feb 20, 2021
The lockorder potential deadlock detection works by remembering for each lock A that is acquired while holding another B the pair (A,B), and triggering a warning when (B,A) already exists in the table. A and B in the above text are represented by pointers to the CCriticalSection object that is acquired. This does mean however that we need to clean up the table entries that refer to any critical section which is destroyed, as it memory address can potentially be used for another unrelated lock in the future. Implement this clean up by remembering not only the pairs in forward direction, but also backward direction. This allows for fast iteration over all pairs that use a deleted CCriticalSection in either the first or the second position. zcash: cherry picked from commit 5eeb913 zcash: bitcoin/bitcoin#7846
zkbot
added a commit
to zcash/zcash
that referenced
this pull request
Apr 1, 2021
Bitcoin 0.13 locking PRs These are locking changes from upstream (bitcoin core) release 0.13, oldest to newest (when they were merged to the master branch). - bitcoin/bitcoin#7846 - bitcoin/bitcoin#7913 - bitcoin/bitcoin#8016 - second commit only; first commit, test changes, are already done - bitcoin/bitcoin#7942 This PR does not include: - bitcoin/bitcoin#8244 bitcoin/bitcoin@27f8126 - zcash requires locking `cs_main` in this instance (`getrawmempool()` calls `mempoolToJSON()`, which calls `chainActive.Height()`).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The lockorder potential deadlock detection works by remembering for each lock A that is acquired while holding another B the pair (A,B), and triggering a warning when (B,A) already exists in the table.
A and B in the above text are represented by pointers to the CCriticalSection object that is acquired. This does mean however that we need to clean up the table entries that refer to any critical section which is destroyed, as its memory address can potentially be used for another unrelated lock in the future.
Implement this clean up by remembering not only the pairs in forward direction, but also backward direction. This allows for fast iteration over all pairs that use a deleted CCriticalSection in either the first or the second position.