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: <CANpmjNNpb7FE8usAhyZXxrVSTL8J00M4QyPUhKLmPNKfzqg=Ww@mail.gmail.com>
Date: Wed, 21 Jan 2026 13:13:57 +0100
From: Marco Elver <elver@...gle.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Gary Guo <gary@...yguo.net>, 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>, 
	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, 20 Jan 2026 at 23:29, Boqun Feng <boqun.feng@...il.com> wrote:
[..]
> > > > 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.
>
> Our C's atomic_long_read() is the same, that is it's like
> memory_order_consume instead memory_order_relaxed.

I see; so it's Rust's Atomic::load(Relaxed) -> atomic_read() ->
READ_ONCE (for most architectures).

> > > On the Rust-side documentation we mentioned that `Relaxed` always preserve
> > > dependency ordering, so yes, it is closer to `consume` in the C11 model.
> >
> > Alright, I missed this.
> > Is this actually enforced, or like the C side's use of "volatile",
> > relies on luck?
> >
>
> I wouldn't call it luck ;-) but we rely on the same thing that C has:
> implementing by using READ_ONCE().

It's the age-old problem of wanting dependently-ordered atomics, but
no compiler actually providing that. Implementing that via "volatile"
is unsound, and always has been. But that's nothing new.

[...]
> > > I think this is a longstanding debate on whether we should actually depend on
> > > dependency ordering or just upgrade everything needs it to acquire. But this
> > > isn't really specific to Rust, and whatever is decided is global to the full
> > > LKMM.
> >
> > Indeed, but the implementation on the C vs. Rust side differ
> > substantially, so assuming it'll work on the Rust side just because
> > "volatile" works more or less on the C side is a leap I wouldn't want
> > to take in my codebase.
> >
>
> Which part of the implementation is different between C and Rust? We
> implement all Relaxed atomics in Rust the same way as C: using C's
> READ_ONCE() and WRITE_ONCE().

I should clarify: Even if the source of the load is "volatile"
(through atomic_read() FFI) and carries through to Rust code, the
compilers, despite sharing LLVM as the code generator, are different
enough that making the assumption just because it works on the C side,
it'll also work on the Rust side, appears to be a stretch for me. Gary
claimed that Rust is more conservative -- in the absence of any
guarantees, being able to quantify the problem would be nice though.

[..]
> > However, given "Relaxed" for the Rust side is already defined to
> > "carry dependencies" then in isolation my original comment is moot and
> > does not apply to this particular patch. At face value the promised
> > semantics are ok, but the implementation (just like "volatile" for C)
> > probably are not. But that appears to be beyond this patch, so feel
>
> Implementation-wise, READ_ONCE() is used the same as C for
> atomic_read(), so Rust and C are on the same boat.

That's fair enough.

Longer term, I understand the need for claiming "it's all fine", but
IMHO none of this is fine until compilers (both for C and Rust)
promise the semantics that the LKMM wants. Nothing new per-se, the
only new thing here that makes me anxious is that we do not understand
the real impact of this lack of guarantee on Linux Rust code (the C
side remains unclear, too, but has a lot more flight miles). Perhaps
the work originally investigating broken dependency ordering in Clang,
could be used to do a study on Rust in the kernel, too.