[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260101.111123.1233018024195968460.fujita.tomonori@gmail.com>
Date: Thu, 01 Jan 2026 11:11:23 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: aliceryhl@...gle.com, lyude@...hat.com, a.hindborg@...nel.org
Cc: boqun.feng@...il.com, will@...nel.org, peterz@...radead.org,
richard.henderson@...aro.org, mattst88@...il.com, linmag7@...il.com,
catalin.marinas@....com, ojeda@...nel.org, gary@...yguo.net,
bjorn3_gh@...tonmail.com, lossin@...nel.org, tmgross@...ch.edu,
dakr@...nel.org, mark.rutland@....com, fujita.tomonori@...il.com,
frederic@...nel.org, tglx@...utronix.de, anna-maria@...utronix.de,
jstultz@...gle.com, sboyd@...nel.org, viro@...iv.linux.org.uk,
brauner@...nel.org, 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 4/5] rust: hrtimer: use READ_ONCE instead of
read_volatile
On Wed, 31 Dec 2025 12:22:28 +0000
Alice Ryhl <aliceryhl@...gle.com> wrote:
> Using `READ_ONCE` is the correct way to read the `node.expires` field.
>
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> ---
> rust/kernel/time/hrtimer.rs | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
> index 856d2d929a00892dc8eaec63cebdf547817953d3..e2b7a26f8aade972356c3eb5f6489bcda3e2e849 100644
> --- a/rust/kernel/time/hrtimer.rs
> +++ b/rust/kernel/time/hrtimer.rs
> @@ -239,11 +239,9 @@ pub fn expires(&self) -> HrTimerInstant<T>
> // - Timers cannot have negative ktime_t values as their expiration time.
> // - There's no actual locking here, a racy read is fine and expected
> unsafe {
> - Instant::from_ktime(
> - // This `read_volatile` is intended to correspond to a READ_ONCE call.
> - // FIXME(read_once): Replace with `read_once` when available on the Rust side.
> - core::ptr::read_volatile(&raw const ((*c_timer_ptr).node.expires)),
> - )
> + Instant::from_ktime(kernel::sync::READ_ONCE(
> + &raw const (*c_timer_ptr).node.expires,
> + ))
> }
Do we actually need READ_ONCE() here? I'm not sure but would it be
better to call the C-side API?
diff --git a/rust/helpers/time.c b/rust/helpers/time.c
index 67a36ccc3ec4..73162dea2a29 100644
--- a/rust/helpers/time.c
+++ b/rust/helpers/time.c
@@ -2,6 +2,7 @@
#include <linux/delay.h>
#include <linux/ktime.h>
+#include <linux/hrtimer.h>
#include <linux/timekeeping.h>
void rust_helper_fsleep(unsigned long usecs)
@@ -38,3 +39,8 @@ void rust_helper_udelay(unsigned long usec)
{
udelay(usec);
}
+
+__rust_helper ktime_t rust_helper_hrtimer_get_expires(const struct hrtimer *timer)
+{
+ return timer->node.expires;
+}
diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
index 856d2d929a00..61e656a65216 100644
--- a/rust/kernel/time/hrtimer.rs
+++ b/rust/kernel/time/hrtimer.rs
@@ -237,14 +237,7 @@ pub fn expires(&self) -> HrTimerInstant<T>
// SAFETY:
// - Timers cannot have negative ktime_t values as their expiration time.
- // - There's no actual locking here, a racy read is fine and expected
- unsafe {
- Instant::from_ktime(
- // This `read_volatile` is intended to correspond to a READ_ONCE call.
- // FIXME(read_once): Replace with `read_once` when available on the Rust side.
- core::ptr::read_volatile(&raw const ((*c_timer_ptr).node.expires)),
- )
- }
+ unsafe { Instant::from_ktime(bindings::hrtimer_get_expires(c_timer_ptr)) }
}
}
Powered by blists - more mailing lists