From 344944794416cfd6824fb2f1bcac90bf787456ed Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 19 May 2025 16:46:27 +0200 Subject: [PATCH 1/2] deliberate UB: add crossbeam-deque --- resources/deliberate-ub.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/resources/deliberate-ub.md b/resources/deliberate-ub.md index 1bec8ae..531094e 100644 --- a/resources/deliberate-ub.md +++ b/resources/deliberate-ub.md @@ -19,6 +19,9 @@ We should evaluate whether there truly is some use-case here that is not current see the [discussion here](https://github.com/rust-lang/unsafe-code-guidelines/issues/449).
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.) +* 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`. + This would be resolved by bytewise atomic memcpy. ### Cases related to aliasing From 0aef121400cab5d267c6804d809911d3fba54bc9 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 19 May 2025 20:30:54 +0200 Subject: [PATCH 2/2] mention that atomic-maybe-uninit is being used to work around this --- resources/deliberate-ub.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/deliberate-ub.md b/resources/deliberate-ub.md index 531094e..158c96c 100644 --- a/resources/deliberate-ub.md +++ b/resources/deliberate-ub.md @@ -18,7 +18,7 @@ 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).
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`. This would be resolved by bytewise atomic memcpy.