[PATCH 4/5] rust: hrtimer: use READ_ONCE instead of read_volatile

[Andreas Hindborg]

FUJITA Tomonori <fujita.tomonori at gmail.com> writes:

> On Tue, 06 Jan 2026 13:37:34 +0100
> Andreas Hindborg <a.hindborg at kernel.org> wrote:
>
>> "FUJITA Tomonori" <fujita.tomonori at gmail.com> writes:
>> 
>>> On Thu, 01 Jan 2026 11:11:23 +0900 (JST)
>>> FUJITA Tomonori <fujita.tomonori at gmail.com> wrote:
>>>
>>>> On Wed, 31 Dec 2025 12:22:28 +0000
>>>> Alice Ryhl <aliceryhl at google.com> wrote:
>>>>
>>>>> Using `READ_ONCE` is the correct way to read the `node.expires` field.
>>>>>
>>>>> Signed-off-by: Alice Ryhl <aliceryhl at google.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;
>>>> +}
>>>
>>> Sorry, of course this should be:
>>>
>>> +__rust_helper ktime_t rust_helper_hrtimer_get_expires(const struct hrtimer *timer)
>>> +{
>>> +	return hrtimer_get_expires(timer);
>>> +}
>>>
>> 
>> This is a potentially racy read. As far as I recall, we determined that
>> using read_once is the proper way to handle the situation.
>> 
>> I do not think it makes a difference that the read is done by C code.
>
> What does "racy read" mean here?
>
> The C side doesn't use WRITE_ONCE() or READ_ONCE for node.expires. How
> would using READ_ONCE() on the Rust side make a difference?

Data races like this are UB in Rust. As far as I understand, using this
READ_ONCE implementation or a relaxed atomic read would make the read
well defined. I am not aware if this is only the case if all writes to
the location from C also use atomic operations or WRITE_ONCE. @Boqun?


Best regards,
Andreas Hindborg