fix data race in ReentrantLock fallback for targets without 64bit atomics by RalfJung · Pull Request #141248 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation7 Commits2 Checks6 Files changed
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
[ Show hidden characters]({{ revealButtonHref }})
See Zulip for details: the address used to identify a thread might get lazily allocated inside tls_addr(), so if we call that after doing the tls_addr.load() it is too late to establish synchronization with prior threads that used the same address -- the load() thus races with the store() by that prior thread, and might hence see outdated values, and then the entire logic breaks down.
r? @joboet
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
The Miri subtree was changed
cc @rust-lang/miri
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test will not be run by bors, only by the Miri test suite on the next sync. I verified it locally.
However we anyway don't have mips-unknown-linux-gnu in the Miri test suite... is there any tier 1 target without 64bit atomics?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so...
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah there is not. rust-lang/miri#4333 adds this mips target so that we will cover this in the future.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, that was subtle...
r=me once CI passes
📌 Commit 26ea763 has been approved by joboet
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
bors added a commit to rust-lang-ci/rust that referenced this pull request
…iaskrgr
Rollup of 6 pull requests
Successful merges:
- rust-lang#131200 (Handle
rustc_query_systemcases ofrustc::potential_query_instabilitylint) - rust-lang#141244 (windows: document that we rely on an undocumented property of GetUserProfileDirectoryW)
- rust-lang#141247 (skip compiler tools sanity checks on certain commands)
- rust-lang#141248 (fix data race in ReentrantLock fallback for targets without 64bit atomics)
- rust-lang#141249 (introduce common macro for
MutVisitorandVisitorto dedup code) - rust-lang#141253 (Warning added when dependency crate has async drop types, and the feature is disabled)
r? @ghost
@rustbot modify labels: rollup
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#141248 - RalfJung:reentrant-lock-race, r=joboet
fix data race in ReentrantLock fallback for targets without 64bit atomics
See Zulip for details: the address used to identify a thread might get lazily allocated inside tls_addr(), so if we call that after doing the tls_addr.load() it is too late to establish synchronization with prior threads that used the same address -- the load() thus races with the store() by that prior thread, and might hence see outdated values, and then the entire logic breaks down.
r? @joboet
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request
…boet
fix data race in ReentrantLock fallback for targets without 64bit atomics
See Zulip for details: the address used to identify a thread might get lazily allocated inside tls_addr(), so if we call that after doing the tls_addr.load() it is too late to establish synchronization with prior threads that used the same address -- the load() thus races with the store() by that prior thread, and might hence see outdated values, and then the entire logic breaks down.
r? @joboet
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the library team, which will review and decide on the PR/issue.