Fix SubscriberStateTable::hasCachedData formula for a timing risk #379
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
Signed-off-by: Qi Luo <[email protected]>
pavel-shirshov
previously approved these changes
Sep 10, 2020
|
it sounds like a critical bug? what releases we need to backport? |
|
Ideally, we need to cherry-pick to all the release branches since 201803. |
Signed-off-by: Qi Luo <[email protected]>
qiluo-msft
changed the title
lguohan
approved these changes
Sep 11, 2020
qiluo-msft
added a commit
that referenced
this pull request
Sep 11, 2020
* Fix hasCachedData formula * Add test case to verify the fix * Remove dead code in test
qiluo-msft
added a commit
that referenced
this pull request
Sep 11, 2020
* Fix hasCachedData formula * Add test case to verify the fix * Remove dead code in test
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.
The issue statement:
If the use case of SubscriberStateTable meets below conditions:
Select::select(), thenSubscriberStateTable::pop()instead ofSubscriberStateTable::pops()There is a rare timing risk inside the implementation of SubscriberStateTable, leading to a state that SubscriberStateTable holds two entries but
Select::select()is stuck. If the table has new change (operation), SubscriberStateTable may recover.The fix:
SubscriberStateTable::hasCachedDatashould return true if there are 2 or more entries internally, including entries inm_bufferwhich were read by previouspops(), or entries inm_keyspace_event_bufferwhich will be read by nextpops().Ideally, we need to cherry-pick to all the release branches since 201803.
Search the code, I found similar use cases, so the same issue is possible to happen at one of the places.