linux-kernel - Re: [PATCH 0/5] Add READ_ONCE and WRITE

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: <87fr8ij4le.fsf@t14s.mail-host-address-is-not-set>
Date: Tue, 06 Jan 2026 13:41:33 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Boqun Feng <boqun.feng@...il.com>, Alice Ryhl <aliceryhl@...gle.com>
Cc: Gary Guo <gary@...yguo.net>, Will Deacon <will@...nel.org>, Peter
 Zijlstra <peterz@...radead.org>, "Paul E. McKenney" <paulmck@...nel.org>,
 Richard Henderson <richard.henderson@...aro.org>, Matt Turner
 <mattst88@...il.com>, Magnus Lindholm <linmag7@...il.com>, Catalin
 Marinas <catalin.marinas@....com>, Miguel Ojeda <ojeda@...nel.org>,
 Björn
 Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
 Trevor
 Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, Mark
 Rutland <mark.rutland@....com>, FUJITA Tomonori
 <fujita.tomonori@...il.com>, Frederic Weisbecker <frederic@...nel.org>,
 Lyude Paul <lyude@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
 Anna-Maria Behnsen <anna-maria@...utronix.de>, John Stultz
 <jstultz@...gle.com>, Stephen Boyd <sboyd@...nel.org>, Alexander Viro
 <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan
 Kara <jack@...e.cz>, linux-kernel@...r.kernel.org,
 linux-alpha@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 rust-for-linux@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/5] Add READ_ONCE and WRITE_ONCE to Rust

"Boqun Feng" <boqun.feng@...il.com> writes:

> On Thu, Jan 01, 2026 at 12:53:39AM +0000, Alice Ryhl wrote:
>> On Wed, Dec 31, 2025 at 03:12:16PM +0000, Gary Guo wrote:
>> > On Wed, 31 Dec 2025 12:22:24 +0000
>> > Alice Ryhl <aliceryhl@...gle.com> wrote:
>> >
>> > > There are currently a few places in the kernel where we use volatile
>> > > reads when we really should be using `READ_ONCE`. To make it possible to
>> > > replace these with proper `READ_ONCE` calls, introduce a Rust version of
>> > > `READ_ONCE`.
>> > >
>> > > A new config option CONFIG_ARCH_USE_CUSTOM_READ_ONCE is introduced so
>> > > that Rust is able to use conditional compilation to implement READ_ONCE
>> > > in terms of either a volatile read, or by calling into a C helper
>> > > function, depending on the architecture.
>> > >
>> > > This series is intended to be merged through ATOMIC INFRASTRUCTURE.
>> >
>> > Hi Alice,
>> >
>> > I would prefer not to expose the READ_ONCE/WRITE_ONCE functions, at
>> > least not with their atomic semantics.
>> >
>> > Both callsites that you have converted should be using
>> >
>> > 	Atomic::from_ptr().load(Relaxed)
>> >
>> > Please refer to the documentation of `Atomic` about this. Fujita has a
>> > series that expand the type to u8/u16 if you need narrower accesses.
>>
>> Why? If we say that we're using the LKMM, then it seems confusing to not
>> have a READ_ONCE() for cases where we interact with C code, and that C
>> code documents that READ_ONCE() should be used.
>>
>
> The problem of READ_ONCE() and WRITE_ONCE() is that the semantics is
> complicated. Sometimes they are used for atomicity, sometimes they are
> used for preventing data race. So yes, we are using LKMM in Rust as
> well, but whenever possible, we need to clarify the intentation of the
> API, using Atomic::from_ptr().load(Relaxed) helps on that front.
>
> IMO, READ_ONCE()/WRITE_ONCE() is like a "band aid" solution to a few
> problems, having it would prevent us from developing a more clear view
> for concurrent programming.

What is the semantics of a non-atomic write in C code under lock racing
with a READ_ONCE/atomic relaxed read in Rust? That is the hrtimer case.

Best regards,
Andreas Hindborg