-
Notifications
You must be signed in to change notification settings - Fork 112
fix: fix a map access race condition in the want index #523
Conversation
ef24152
to
c0ce901
Compare
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.
Seems reasonable. Is the problem here that we're calling e.peerLedger.CancelWant
without taking the lock on the ledger?
internal/decision/engine.go
Outdated
if hasLedger { | ||
ledger.lk.RLock() | ||
} | ||
for _, k := range wl { | ||
if hasLedger { | ||
if _, has := ledger.WantListContains(k); has { | ||
continue | ||
} | ||
} | ||
e.peerLedger.CancelWant(p, k) | ||
} | ||
if hasLedger { | ||
ledger.lk.RUnlock() | ||
} |
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.
nit: IMO it'd be easier to read this if we separated all the hasLedger
pieces out and just had an if/else or an if + return.
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.
Yeah, good point.
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.
Done
Yes. On the happy path we just read the map so we only need a read lock. On the sad path, we need to take the lock. |
fix: fix a map access race condition in the want index This commit was moved from ipfs/go-bitswap@5c2c537
We should have better tests here, but I'm not sure how to go about that. We basically need a fuzzer.