linux-kernel - Re: [PATCH 2/2] rust: sync: atomic: Add atomic operation helpers over raw pointers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aW-sGiEQg1mP6hHF@elver.google.com>
Date: Tue, 20 Jan 2026 17:23:54 +0100
From: Marco Elver <elver@...gle.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, kasan-dev@...glegroups.com,
	Will Deacon <will@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mark Rutland <mark.rutland@....com>, Gary Guo <gary@...yguo.net>,
	Miguel Ojeda <ojeda@...nel.org>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>,
	Elle Rhumsaa <elle@...thered-steel.dev>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	FUJITA Tomonori <fujita.tomonori@...il.com>
Subject: Re: [PATCH 2/2] rust: sync: atomic: Add atomic operation helpers
 over raw pointers

On Tue, Jan 20, 2026 at 07:52PM +0800, Boqun Feng wrote:
> In order to synchronize with C or external, atomic operations over raw
> pointers, althought previously there is always an `Atomic::from_ptr()`
> to provide a `&Atomic<T>`. However it's more convenient to have helpers
> that directly perform atomic operations on raw pointers. Hence a few are
> added, which are basically a `Atomic::from_ptr().op()` wrapper.
> 
> Note: for naming, since `atomic_xchg()` and `atomic_cmpxchg()` has a
> conflict naming to 32bit C atomic xchg/cmpxchg, hence they are just
> named as `xchg()` and `cmpxchg()`. For `atomic_load()` and
> `atomic_store()`, their 32bit C counterparts are `atomic_read()` and
> `atomic_set()`, so keep the `atomic_` prefix.
> 
> Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> ---
>  rust/kernel/sync/atomic.rs           | 104 +++++++++++++++++++++++++++
>  rust/kernel/sync/atomic/predefine.rs |  46 ++++++++++++
>  2 files changed, 150 insertions(+)
> 
> diff --git a/rust/kernel/sync/atomic.rs b/rust/kernel/sync/atomic.rs
> index d49ee45c6eb7..6c46335bdb8c 100644
> --- a/rust/kernel/sync/atomic.rs
> +++ b/rust/kernel/sync/atomic.rs
> @@ -611,3 +611,107 @@ pub fn cmpxchg<Ordering: ordering::Ordering>(
>          }
>      }
>  }
> +
> +/// Atomic load over raw pointers.
> +///
> +/// This function provides a short-cut of `Atomic::from_ptr().load(..)`, and can be used to work
> +/// with C side on synchronizations:
> +///
> +/// - `atomic_load(.., Relaxed)` maps to `READ_ONCE()` when using for inter-thread communication.
> +/// - `atomic_load(.., Acquire)` maps to `smp_load_acquire()`.

I'm late to the party and may have missed some discussion, but it might
want restating in the documentation and/or commit log:

READ_ONCE is meant to be a dependency-ordering primitive, i.e. be more
like memory_order_consume than it is memory_order_relaxed. This has, to
the best of my knowledge, not changed; otherwise lots of kernel code
would be broken. It is known to be brittle [1]. So the recommendation
above is unsound; well, it's as unsound as implementing READ_ONCE with a
volatile load.

While Alice's series tried to expose READ_ONCE as-is to the Rust side
(via volatile), so that Rust inherits the exact same semantics (including
its implementation flaw), the recommendation above is doubling down on
the unsoundness by proposing Relaxed to map to READ_ONCE.

[1] https://lpc.events/event/16/contributions/1174/attachments/1108/2121/Status%20Report%20-%20Broken%20Dependency%20Orderings%20in%20the%20Linux%20Kernel.pdf

Furthermore, LTO arm64 promotes READ_ONCE to an acquire (see
arch/arm64/include/asm/rwonce.h):

        /*
         * When building with LTO, there is an increased risk of the compiler
         * converting an address dependency headed by a READ_ONCE() invocation
         * into a control dependency and consequently allowing for harmful
         * reordering by the CPU.
         *
         * Ensure that such transformations are harmless by overriding the generic
         * READ_ONCE() definition with one that provides RCpc acquire semantics
         * when building with LTO.
         */

So for all intents and purposes, the only sound mapping when pairing
READ_ONCE() with an atomic load on the Rust side is to use Acquire
ordering.