Skip to content

deliberate UB: add crossbeam-deque #568

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
May 19, 2025
Merged

deliberate UB: add crossbeam-deque #568

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3449447
deliberate UB: add crossbeam-deque
RalfJung May 19, 2025
0aef121
mention that atomic-maybe-uninit is being used to work around this
RalfJung May 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion resources/deliberate-ub.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,10 @@ We should evaluate whether there truly is some use-case here that is not current
It is not clear how to best specify a useful `compare_exchange` that can work on padding bytes,
see the [discussion here](https://github.com/rust-lang/unsafe-code-guidelines/issues/449).<br>
The alternative is to not use the "fast path" for problematic types (and fall back to the SeqLock), but that requires some way to query at `const`-time whether the type contains padding (or provenance).
(Or of course one can use inline assembly, but it would be better if that was not required.)
(Or of course one can use inline assembly, but it would be better if that was not required. This is in fact what crossbeam now does, via [atomic-maybe-uninit](https://github.com/taiki-e/atomic-maybe-uninit).)
* crossbeam's deque uses [volatile accesses that really should be atomic instead](https://github.com/crossbeam-rs/crossbeam/blob/5a154def002304814d50f3c7658bd30eb46b2fad/crossbeam-deque/src/deque.rs#L70-L88).
They cannot use atomic accesses as those are not possible for arbitrary `T`.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@taiki-e do you know if atomic bytewise memcpy (rust-lang/rfcs#3301) would solve this problem? It sure looks like it would.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I mentioned the use in crossbeam-deque in that RFC over 2 years ago.

Copy link
Member

@taiki-e taiki-e May 19, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, as mentioned in crossbeam-rs/crossbeam#1015 ("AtomicCell: Use atomic-maybe-uninit"), crossbeam-deque will likely be using atomic-maybe-uninit for non-{miri,tsan} cases to resolve this issue for now.

It is possible to use atomic-maybe-uninit crate to fix UB of concurrent access with volatile read/write in seqlock/deque (#744, #859), but that is not included in this PR and is left to subsequent PRs.

This would be resolved by bytewise atomic memcpy.

### Cases related to aliasing

Expand Down
Loading