-
Notifications
You must be signed in to change notification settings - Fork 38.6k
net: make m_nodes_mutex non-recursive #32394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32394. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please copy-paste ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Concept ACK on that. |
|
|
22d4c57 to
9a49877
Compare
|
|
|
Time to rebase once more? |
|
|
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK 492be23a1873d7165e6cc75d1282f4feb63f87b9
|
|
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 4aad3714d66cc80c08cb1c827fb49fba7dcf8d50
All annotations make sense, but left Q regarding 1-2 potentially missing ones.
|
|
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 4b3a2c23608e709a63b9d5bd69c3eb16cf08e462
Manually went through all functions using CConnman::m_nodes_mutex and only remaining issue I could find is now fixed (https://github.com/bitcoin/bitcoin/pull/32394/files#r2433600255).
Also checked out first commit and only cherrypicked mutex type change to re-confirm Clang spews warnings about missing annotations (and no warnings at HEAD of PR).
|
Approach ACK |
|
|
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-ACK 1a9274f391df0465c17b6b6664988af70910e39b
Changes since previous review (#32394 (review)):
- Resolves conflict with #32983.
Crypt-iQ
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
crACK 1a9274f391df0465c17b6b6664988af70910e39b
Needs a small rebase since #33956 added 2 annotations.
| pnodeStop->m_bip152_highbandwidth_to = false; | ||
| return true; | ||
| }); | ||
| lNodesAnnouncingHeaderAndIDs.pop_front(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was initially concerned that maybe lNodesAnnouncingHeaderAndIDs.front() could have been removed from in between releasing the lock and acquiring the lock again. It seems fine since if we do not find lNodesAnnouncingHeaderAndIDs.front(), we don't need to set m_bip152_highbandwidth_to false and we still remove it from the list. There was some previous discussion about the locking here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed from in between releasing the lock and acquiring the lock again
How? lNodesAnnouncingHeaderAndIDs is protected by cs_main which is held in the entire PeerManagerImpl::MaybeSetPeerAsAnnouncingHeaderAndIDs().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I was a little unclear. I meant that the CNode* that lNodesAnnouncingHeaderAndIDs.front() refers to might have been removed from in m_nodes if we're not holding m_nodes_mutex the entire time. Though I did not write a test to check if this is actually possible, so I might be wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that seems to be fine - if the last m_connman.ForNode(...front()) does nothing (the one at the end, just before pop_front()).
The only recursive usage of `CConnman::m_nodes_mutex` is from
`PeerManagerImpl::MaybeSetPeerAsAnnouncingHeaderAndIDs()` which uses
nested calls to `CConnman::ForNode()` to trim the size of
`lNodesAnnouncingHeaderAndIDs` to `<= 3`. This need not be nested, so
take it out.
Before:
```
fornode(newnode)
if (size >= 3)
fornode(front) handle removal of front
pop front
push back newnode
```
After:
```
fornode(newnode)
push back newnode
if (size > 3)
fornode(front) handle removal of front
pop front
```
`lNodesAnnouncingHeaderAndIDs` is protected by `cs_main` which is locked
during the entire operation.
This change includes `s/RecursiveMutex/Mutex/` and a pile of annotations to keep the compiler happy after the type change. Partially resolves: bitcoin#19303
|
|
|
re-ACK a6ccd6f |
hodlinator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
🐙 This pull request conflicts with the target branch and needs rebase. |
The only case of a recursive lock was a nested
ForNode()call to trimthe size of
lNodesAnnouncingHeaderAndIDsto<= 3. This need not benested, so take it out.
Before:
After:
lNodesAnnouncingHeaderAndIDsis protected bycs_mainwhich is lockedduring the entire operation.
Partially resolves: #19303
This PR included #32326 (first 3 commits in this PR). That PR was merged first, so the size of this was reduced.