i#6373: handle back-to-back signals after an rseq abort. #6374
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
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.
When a signal causes an rseq abort, there will be a rseq abort marker, followed by a kernel event marker.
When another signal follows immediately, another kernel event maker will be added with a different value.
If a back-to-back signal happens without any intervening instructions, the new kernel event marker (3rd one) should have the same value as the second kernel event marker.
The current implementation of the invariant check fails to consider this case, and flag an error.
If the instruction before the rseq marker is a branch, the invariant checker reports "Branch does not go to the correct target @ kernel_event marker", otherwise it reports "Non-explicit control flow has no marker @ kernel_event marker".
The fix is to check if the kernel event marker has the same value as the previous one, and if there are no intervening instructions between signals, do not flag an error.
Fixes: #6373