From: Gary Guo <gary@garyguo.net>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Boqun Feng" <boqun.feng@gmail.com>,
"Will Deacon" <will@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Matt Turner" <mattst88@gmail.com>,
"Magnus Lindholm" <linmag7@gmail.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"FUJITA Tomonori" <fujita.tomonori@gmail.com>,
"Frederic Weisbecker" <frederic@kernel.org>,
"Lyude Paul" <lyude@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Anna-Maria Behnsen" <anna-maria@linutronix.de>,
"John Stultz" <jstultz@google.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Jan Kara" <jack@suse.cz>,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
rust-for-linux@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/5] rust: sync: support using bool with READ_ONCE
Date: Wed, 31 Dec 2025 15:25:34 +0000 [thread overview]
Message-ID: <20251231152534.14903719.gary@garyguo.net> (raw)
In-Reply-To: <20251231-rwonce-v1-3-702a10b85278@google.com>
On Wed, 31 Dec 2025 12:22:27 +0000
Alice Ryhl <aliceryhl@google.com> wrote:
> Normally it is undefined behavior for a bool to take any value other
> than 0 or 1. However, in the case of READ_ONCE(some_bool) is used, this
> UB seems dangerous and unnecessary. I can easily imagine some Rust code
> that looks like this:
>
> if READ_ONCE(&raw const (*my_c_struct).my_bool_field) {
> ...
> }
>
> And by making an analogy to what the equivalent C code is, anyone
> writing this probably just meant to treat any non-zero value as true.
In C, bool can only hold value `false` and `true`, too, and putting
any other value there is going to be UB.
The C language provides automatic cast so when you write an integer to it,
non-zero values will cause `true` to be written. However, you're not
allowed to cast it into a char ptr and write other values into it.
So I think there shouldn't be any special treatment to boolean type in
this regard.
Best,
Gary
>
> For WRITE_ONCE no special logic is required.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> rust/kernel/sync/rwonce.rs | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/rust/kernel/sync/rwonce.rs b/rust/kernel/sync/rwonce.rs
> index a1660e43c9ef94011812d1816713cf031a73de1d..73477f53131926996614df573b2d50fff98e624f 100644
> --- a/rust/kernel/sync/rwonce.rs
> +++ b/rust/kernel/sync/rwonce.rs
> @@ -163,6 +163,7 @@ unsafe fn write_once(ptr: *mut Self, val: Self) {
> // sizes, so picking the wrong helper should lead to a build error.
>
> impl_rw_once_type! {
> + bool, read_once_bool, write_once_1;
> u8, read_once_1, write_once_1;
> i8, read_once_1, write_once_1;
> u16, read_once_2, write_once_2;
> @@ -186,3 +187,21 @@ unsafe fn write_once(ptr: *mut Self, val: Self) {
> usize, read_once_8, write_once_8;
> isize, read_once_8, write_once_8;
> }
> +
> +/// Read an integer as a boolean once.
> +///
> +/// Returns `true` if the value behind the pointer is non-zero. Otherwise returns `false`.
> +///
> +/// # Safety
> +///
> +/// It must be safe to `READ_ONCE` the `ptr` with type `u8`.
> +#[inline(always)]
> +#[track_caller]
> +unsafe fn read_once_bool(ptr: *const bool) -> bool {
> + // Implement `read_once_bool` in terms of `read_once_1`. The arch-specific logic is inside
> + // of `read_once_1`.
> + //
> + // SAFETY: It is safe to `READ_ONCE` the `ptr` with type `u8`.
> + let byte = unsafe { read_once_1(ptr.cast::<u8>()) };
> + byte != 0u8
> +}
>
next prev parent reply other threads:[~2025-12-31 15:25 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 12:22 [PATCH 0/5] Add READ_ONCE and WRITE_ONCE to Rust Alice Ryhl
2025-12-31 12:22 ` [PATCH 1/5] arch: add CONFIG_ARCH_USE_CUSTOM_READ_ONCE for arm64/alpha Alice Ryhl
2025-12-31 12:22 ` [PATCH 2/5] rust: sync: add READ_ONCE and WRITE_ONCE Alice Ryhl
2026-01-06 12:29 ` Andreas Hindborg
2026-01-06 12:53 ` Boqun Feng
2025-12-31 12:22 ` [PATCH 3/5] rust: sync: support using bool with READ_ONCE Alice Ryhl
2025-12-31 15:25 ` Gary Guo [this message]
2026-01-06 12:43 ` Peter Zijlstra
2026-01-06 12:51 ` Alice Ryhl
2026-01-06 18:12 ` Gary Guo
2026-01-07 8:33 ` Peter Zijlstra
2026-01-07 18:12 ` Gary Guo
2025-12-31 12:22 ` [PATCH 4/5] rust: hrtimer: use READ_ONCE instead of read_volatile Alice Ryhl
2026-01-01 2:11 ` FUJITA Tomonori
2026-01-01 4:00 ` FUJITA Tomonori
2026-01-06 12:37 ` Andreas Hindborg
2026-01-06 13:28 ` FUJITA Tomonori
2026-01-07 10:11 ` Andreas Hindborg
2026-01-07 11:22 ` FUJITA Tomonori
2026-01-07 18:21 ` Andreas Hindborg
2026-01-09 2:10 ` FUJITA Tomonori
2026-01-09 10:42 ` Andreas Hindborg
2026-01-07 11:51 ` Boqun Feng
2026-01-07 12:48 ` Andreas Hindborg
2026-01-06 15:23 ` Gary Guo
2026-01-06 18:43 ` Alice Ryhl
2026-01-07 0:47 ` John Hubbard
2026-01-07 1:08 ` Boqun Feng
2026-01-07 2:59 ` John Hubbard
2026-01-07 1:18 ` Boqun Feng
2025-12-31 12:22 ` [PATCH 5/5] rust: fs: " Alice Ryhl
2026-01-21 0:47 ` Boqun Feng
2025-12-31 15:12 ` [PATCH 0/5] Add READ_ONCE and WRITE_ONCE to Rust Gary Guo
2026-01-01 0:53 ` Alice Ryhl
2026-01-01 1:13 ` Boqun Feng
2026-01-06 12:41 ` Andreas Hindborg
2026-01-06 13:09 ` Boqun Feng
2026-01-06 14:56 ` Peter Zijlstra
2026-01-06 18:18 ` Paul E. McKenney
2026-01-06 19:28 ` Marco Elver
2026-01-09 2:09 ` Paul E. McKenney
2026-01-09 12:00 ` Marco Elver
2026-01-07 8:43 ` Peter Zijlstra
2026-01-07 19:17 ` Paul E. McKenney
-- strict thread matches above, loose matches on Subject: below --
2026-01-06 18:10 [PATCH 3/5] rust: sync: support using bool with READ_ONCE Jubilee Young
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251231152534.14903719.gary@garyguo.net \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=anna-maria@linutronix.de \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dakr@kernel.org \
--cc=frederic@kernel.org \
--cc=fujita.tomonori@gmail.com \
--cc=jack@suse.cz \
--cc=jstultz@google.com \
--cc=linmag7@gmail.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=mark.rutland@arm.com \
--cc=mattst88@gmail.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=richard.henderson@linaro.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox