-
Notifications
You must be signed in to change notification settings - Fork 24.3k
[torch][cuda] fix race condition in cuda initialization #143238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The access to lazy init callbacks (`_lazy_seed_tracker` and `_queued_calls`) is not synchronized with the initialization lock. This exposes us to the following race: 1. start `_lazy_init` 2. take `_initialization_lock` 3. flush `_queued_calls` and run them all 4. <another thread> comes in and uses `_lazy_call` to put something on the queue (in our case, the manual_seed) 5. original thread finishes initializing, but never runs that call
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/143238
Note: Links to docs will display an error until the docs builds have been completed. ❗ 1 Active SEVsThere are 1 currently active SEVs. If your PR is affected, please view them below: ✅ You can merge normally! (1 Unrelated Failure)As of commit 3b2a844 with merge base 8621b9f ( FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
The access to lazy init callbacks (`_lazy_seed_tracker` and `_queued_calls`) is not synchronized with the initialization lock. This exposes us to the following race: 1. start `_lazy_init` 2. take `_initialization_lock` 3. flush `_queued_calls` and run them all 4. another thread comes in and uses `_lazy_call` to put something on the queue (in our case, the `manual_seed`) 5. original thread finishes initializing, but never runs that call Pull Request resolved: pytorch#143238 Approved by: https://github.com/ngimel
It looks like this PR did not make it into 2.6 release? Could this be considered for a backport candidate for 2.6.1 or something? |
The access to lazy init callbacks (
_lazy_seed_tracker
and_queued_calls
) is not synchronized with the initialization lock.This exposes us to the following race:
_lazy_init
_initialization_lock
_queued_calls
and run them all_lazy_call
to put something on the queue (in our case, themanual_seed
)