Atomic-less approach to fixing the double release race condition #102
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
sbSteveK
approved these changes
Jul 3, 2023
graebm
reviewed
Jul 3, 2023
| aws_mutex_unlock(&connection->stream_lock); | ||
|
|
||
| /* Note that we do not invoke callback while holding lock */ | ||
| s_complete_continuation(continuation); | ||
| if (was_present) { | ||
| s_complete_continuation(continuation); |
There was a problem hiding this comment.
This improves things, but I'm still worried about s_clear_continuation_table() (which is called from aws_event_stream_rpc_client_connection_close() and s_on_channel_shutdown_fn())
It seems to mark ALL continuations closed, and fire their callbacks, but does NOT remove them from the hashtable. I'm haven't dug through every possible execution path, but this seems fragile, like we could do the callback/release but leave them in the table, then callback/release again from one of these places you just fixed
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.
Ensure that the continuation completion callbacks and its table-remove/decref only get performed once no matter what the situation.
Greengrass has a high-level repro and the logs show the completion callback and the decref inside occuring twice for the same continuation, once due to terminate stream flags on the outbound client socket write callback and once due to terminate stream flags received in the meantime from the server's response.
I was not able to come up with a test with the existing framework that triggered this condition.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.