p2p/discover: fix crash when revalidated node is removed #29864
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
lightclient
reviewed
May 28, 2024
Contributor
Author
|
After looking into this a bit more, I now think the whole idea of tracking the origin list for revalidation requests is wrong. The list a node is contained in can change while a request is in progress. We should just store the current revalidation list in |
lightclient
reviewed
May 28, 2024
lightclient
approved these changes
May 28, 2024
|
hi |
This was referenced Jun 5, 2024
18 tasks
jorgemmsilva
pushed a commit
to iotaledger/go-ethereum
that referenced
this pull request
Jun 17, 2024
) In ethereum#29572, I assumed the revalidation list that the node is contained in could only ever be changed by the outcome of a revalidation request. But turns out that's not true: if the node gets removed due to FINDNODE failure, it will also be removed from the list it is in. This causes a crash. The invariant is: while node is in table, it is always in exactly one of the two lists. So it seems best to store a pointer to the current list within the node itself.
maoueh
pushed a commit
to streamingfast/go-ethereum
that referenced
this pull request
Aug 1, 2024
) In ethereum#29572, I assumed the revalidation list that the node is contained in could only ever be changed by the outcome of a revalidation request. But turns out that's not true: if the node gets removed due to FINDNODE failure, it will also be removed from the list it is in. This causes a crash. The invariant is: while node is in table, it is always in exactly one of the two lists. So it seems best to store a pointer to the current list within the node itself.
This was referenced Dec 9, 2024
This was referenced Feb 14, 2025
jakub-freebit
pushed a commit
to fblch/go-ethereum
that referenced
this pull request
Jul 23, 2025
) In ethereum#29572, I assumed the revalidation list that the node is contained in could only ever be changed by the outcome of a revalidation request. But turns out that's not true: if the node gets removed due to FINDNODE failure, it will also be removed from the list it is in. This causes a crash. The invariant is: while node is in table, it is always in exactly one of the two lists. So it seems best to store a pointer to the current list within the node itself.
jakub-freebit
pushed a commit
to fblch/go-ethereum
that referenced
this pull request
Sep 3, 2025
) In ethereum#29572, I assumed the revalidation list that the node is contained in could only ever be changed by the outcome of a revalidation request. But turns out that's not true: if the node gets removed due to FINDNODE failure, it will also be removed from the list it is in. This causes a crash. The invariant is: while node is in table, it is always in exactly one of the two lists. So it seems best to store a pointer to the current list within the node itself.
jakub-freebit
pushed a commit
to fblch/go-ethereum
that referenced
this pull request
Sep 4, 2025
) In ethereum#29572, I assumed the revalidation list that the node is contained in could only ever be changed by the outcome of a revalidation request. But turns out that's not true: if the node gets removed due to FINDNODE failure, it will also be removed from the list it is in. This causes a crash. The invariant is: while node is in table, it is always in exactly one of the two lists. So it seems best to store a pointer to the current list within the node itself.
jakub-freebit
pushed a commit
to fblch/go-ethereum
that referenced
this pull request
Sep 16, 2025
) In ethereum#29572, I assumed the revalidation list that the node is contained in could only ever be changed by the outcome of a revalidation request. But turns out that's not true: if the node gets removed due to FINDNODE failure, it will also be removed from the list it is in. This causes a crash. The invariant is: while node is in table, it is always in exactly one of the two lists. So it seems best to store a pointer to the current list within the node itself.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #29860