Repository navigation
eth/protocols/eth, eth/downloader: backport partial receipt deadlock … - #3825
Conversation
Pull Request ReviewThis Go/Ethereum P2P protocol backport fixes an eth/70 partial-receipt cancellation deadlock by routing continuation requests through the peer dispatcher and tying receipt-buffer cleanup to request lifecycle callbacks. It also rejects incomplete responses that make no progress, normalizes downloader capacity estimates across multiple round trips, and adds regression and continuation tests. Sensitive ContentNo sensitive content detected. Security IssuesNo serious security issues detected. Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits. |
…#35537) When an eth/70 receipts response arrives with LastBlockIncomplete set, requestPartialReceipts re-requested the remainder while holding receiptBufferLock across the dispatch. That dispatch blocks until the dispatcher loop accepts the request. If the loop is concurrently cancelling a request for that peer, its cleanup takes the same receiptBufferLock. The dispatcher then waits for the lock the re-request holds while the re-request waits on a channel only the dispatcher reads. The fix releases the lock before sending and routes the follow-up through the dispatcher as a new resend request. --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com> (cherry picked from commit c57bbe4)
…nses (#35593) eth/70 can complete a receipts request over multiple round trips. Current implementation has two issues in requester side. 1. A peer could keep a request loop alive with incomplete responses that deliver no receipt. An incomplete response must now add at least one receipt. A trailing empty list after other blocks is still accepted. We already have a grace period and peer-dropping logic covering this, but an additional guard is nice to have. 2. Response.Time is recorded across all rounds, making the peer's roundtrip estimate incorrect. The dispatcher now counts the rounds made under a request id, and the downloader divides the delivered items and elapsed time to one round trip. (cherry picked from commit 596096a)
…ion and continuation
679c2fb to
370a8b1
Compare
Pull Request ReviewThis Go Ethereum P2P protocol backport fixes an eth/70 partial-receipt cancellation deadlock by routing continuation requests through the dispatcher and tying receipt-buffer cleanup to request lifecycle events. It also rejects incomplete responses that make no progress, normalizes peer-capacity measurements across multiple round trips, and adds regression and continuation tests. Sensitive ContentNo sensitive content detected. Security IssuesNo serious security issues detected. Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits. |
Description
Cherry-picks of ethereum/go-ethereum#35537 and ethereum/go-ethereum#35593 (both merged upstream after v1.17.3), kept as separate commits with their original authorship; a third commit adds BSC-side regression tests..
During SnapSync, an eth/70 partial-receipt continuation can deadlock with a concurrent request cancellation on the same peer. The receipt handler holds receiptBufferLock while waiting for the dispatcher, while the dispatcher processes cancellation and waits for that lock. This can also block the downloader’s receipt-fetching or cancellation flow and stall synchronization on the affected node. A malicious peer can influence when the continuation path runs, but deterministic remote triggering has not been demonstrated.
Rationale
receiptBufferLock(#35537).TestBufferReceiptsNoProgress(upstream),TestPartialReceiptsCancelDoesNotDeadlock(sets the racing interleaving up explicitly; deadlocks on the old code within a few rounds) andTestPartialReceiptsContinuation(happy path: follow-up contExample
add an example CLI or API response...
Changes
Notable changes: