sql: fix a possible race between Flow.Cleanup and Flow.Cancel #95522
Conversation
This file contains 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
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This change is |
Release note: None
yuzefovich
force-pushed
the
setup-flow-follow-up
branch
from
5f338a4 to
d525206
Compare
yuzefovich
changed the title
This commit fixes a possible race that could occur when `Flow.Cleanup` is called by the main goroutine concurrently with `Flow.Cancel` by the listener goroutine (which is not allowed). We already had synchronization in place, but it was insufficient. In particular, the following scenario could lead to a nil pointer crash: - the listener checks whether `Cleanup` has been called, it hasn't, and the mutex is unlocked; - the listener is preemptied; - the main goroutine proceeds to perform the `Cleanup`. At the very end the flow object is unset (including `ctxCancel` overwritten to `nil`); - the listener resumes its execution, proceeds to call `Cancel` on the already-unset `Flow` object, leading to a nil pointer on `ctxCancel` call. This is now fixed by holding the mutex through the call to `Cancel` in the listener goroutine, ensuring that the `Flow` object is not unset from under the listener. Additionally, this commit clarifies the callbacks that are performed at the very beginning and very end of `Cleanup` method. Release note: None
yuzefovich
force-pushed
the
setup-flow-follow-up
branch
from
d525206 to
23da047
Compare
|
I added another commit that fixes another (although less frequent) race. RFAL. |
msirek
approved these changes
Jan 19, 2023
There was a problem hiding this comment.
Very nice!
Reviewed 1 of 1 files at r1, 5 of 5 files at r2, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @andreimatei)
andreimatei
reviewed
Jan 19, 2023
There was a problem hiding this comment.
Reviewable status:
|
TFTRs! bors r+ |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This commit fixes a possible race that could occur when
Flow.Cleanupis called by the main goroutine concurrently with
Flow.Cancelby thelistener goroutine (which is not allowed). We already had
synchronization in place, but it was insufficient. In particular, the
following scenario could lead to a nil pointer crash:
Cleanuphas been called, it hasn't, andthe mutex is unlocked;
Cleanup. At the very endthe flow object is unset (including
ctxCanceloverwritten tonil);Cancelon thealready-unset
Flowobject, leading to a nil pointer onctxCancelcall.
This is now fixed by holding the mutex through the call to
Cancelinthe listener goroutine, ensuring that the
Flowobject is not unsetfrom under the listener. Additionally, this commit clarifies the
callbacks that are performed at the very beginning and very end of
Cleanupmethod.Fixes: #95527.
Release note: None