Fix timing hole releasing safe point VM access #978
Merged
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
When releasing safe point VM access, the vmThreadListMutex must be released after resetting the VM safePointState in order to prevent newly-created threads from incorrectly setting the halted at safe point bit. The vmThreadListMutex is held for the entirety of the safe point, and it is also required while creating a new thread, so new threads will not be created during the safe point. Releasing the vmThreadListMutex early allows the thread creation code to proceed, where it examines the safePointState and incorrectly set the halt bit which will never be cleared, causing VM access acquisition to block forever. Signed-off-by: Graham Chapman <graham_chapman@ca.ibm.com>
DanHeidinga
reviewed
Jan 18, 2018
There was a problem hiding this comment.
LGTM
Lock order is correct. As GAC pointed out on Slack, the comment at the top of the file describes lock order:
/* Note the required ordering of monitors related to VM access:
*
* vm->threadListMutex
* before
* Any number of vmThread->publicFlagsMutex (there is one per thread)
* before
* vm->exclusiveAccessMutex
*
* It is not necessary to always acquire all of the monitors, but whenever more than
* one monitor is acquired, the above ordering must be maintained.
*/
DanHeidinga
approved these changes
Jan 18, 2018
|
Jenkins test sanity plinux |
|
It looks like the PR build passed: But I'll give it one more chance to actually become a checkmark... Jenkins test sanity plinux Edit: Looks like this is the #968 issue cropping up again. |
The thing to note is that there should be ~21152 tests run in the PR build. The previous test run aborted early and didn't complete the test run. Its unfortunate that message shows up, I've opened #981. |
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 releasing safe point VM access, the vmThreadListMutex must be
released after resetting the VM safePointState in order to prevent
newly-created threads from incorrectly setting the halted at safe point
bit.
The vmThreadListMutex is held for the entirety of the safe point, and it
is also required while creating a new thread, so new threads will not be
created during the safe point. Releasing the vmThreadListMutex early
allows the thread creation code to proceed, where it examines the
safePointState and incorrectly set the halt bit which will never be
cleared, causing VM access acquisition to block forever.
Signed-off-by: Graham Chapman graham_chapman@ca.ibm.com