Fix race condition right after ubf registration#16307
Merged
luke-gru merged 1 commit intoruby:masterfrom Mar 9, 2026
Merged
Conversation
4435d8c to
eb8fc15
Compare
Registering a ubf was considered problematic in some cases because it could result in lock ordering inversions with the ubf function itself. I believe this is the reason that in patch be1bbd5, the ubf was registered outside of the `thread_sched_lock`. For example, `thread_sched_to_waiting_until_wakeup()` (native_sleep) should register the ubf with the thread_sched_lock (TSL) taken. The ordering is (TSL -> UBF lock). During the ubf call itself, since the UBF lock is always acquired during the call, the ordering is (UBF lock -> TSL). This inversion was avoided by registering the ubf outside the TSL. This inversion is benign in this case, though. Since there can be no ubf on the thread before the call to `ubf_set`, and this ubf is the only place where the (UBF lock -> TSL lock) ordering is done, it is okay to register it with the TSL. In fact registering the ubf outside the TSL can result in problamatic race conditions, so we now register the ubf with the TSL lock. This fixes a race condition whereby a newly registered ubf is called before the thing it's protecting (the sleep) is actually run. The sleeping thread can never be interrupted if this happens. Fixes [Bug #21926]
eb8fc15 to
dc99d65
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Registering a ubf was considered problematic in some cases because it could
result in lock ordering inversions with the ubf function itself. I believe
this is the reason that in patch be1bbd5, the ubf was registered outside of
the
thread_sched_lock.For example,
thread_sched_to_waiting_until_wakeup()(native_sleep)should register the ubf with the thread_sched_lock (TSL) taken. The ordering
is (TSL -> UBF lock). During the ubf call itself, since the UBF lock is
always acquired during the call, the ordering is (UBF lock -> TSL). This
inversion was avoided by registering the ubf outside the TSL.
This inversion is benign in this case, though. Since there can be no ubf on the
thread before the call to
ubf_set, and this ubf is the only place where the(UBF lock -> TSL lock) ordering is done, it is okay to register it with the TSL.
In fact registering the ubf outside the TSL can result in problamatic race conditions,
so we now register the ubf with the TSL lock.
This fixes a race condition whereby a newly registered ubf is called before the thing it's
protecting (the sleep) is actually run. The sleeping thread can never be interrupted if this
happens.
Fixes [Bug #21926]