| 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
| ||
|
Message-Id: <20260109.111025.1944772328156797586.fujita.tomonori@gmail.com>
Date: Fri, 09 Jan 2026 11:10:25 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: a.hindborg@...nel.org
Cc: fujita.tomonori@...il.com, aliceryhl@...gle.com, lyude@...hat.com,
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, 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, 07 Jan 2026 19:21:11 +0100
Andreas Hindborg <a.hindborg@...nel.org> wrote:
> "FUJITA Tomonori" <fujita.tomonori@...il.com> writes:
>
>> On Wed, 07 Jan 2026 11:11:43 +0100
>> Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>>> FUJITA Tomonori <fujita.tomonori@...il.com> writes:
>>>
>>>> On Tue, 06 Jan 2026 13:37:34 +0100
>>>> Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>>>
>>>>> "FUJITA Tomonori" <fujita.tomonori@...il.com> writes:
>>>>>
>>>>>> On Thu, 01 Jan 2026 11:11:23 +0900 (JST)
>>>>>> FUJITA Tomonori <fujita.tomonori@...il.com> wrote:
>>>>>>
>>>>>>> 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;
>>>>>>> +}
>>>>>>
>>>>>> 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?
>>
>> The C side updates node.expires without WRITE_ONCE()/atomics so a
>> Rust-side READ_ONCE() can still observe a torn value; I think that
>> this is still a data race / UB from Rust's perspective.
>>
>> And since expires is 64-bit, WRITE_ONCE() on 32-bit architectures does
>> not inherently guarantee tear-free stores either.
>>
>> I think that the expires() method should follow the same safety
>> requirements as raw_forward(): it should only be considered safe when
>> holding exclusive access to hrtimer or within the context of the timer
>> callback. Under those conditions, it would be fine to call C's
>> hrtimer_get_expires().
>
> We can make it safe, please see my comment here [1].
>
> Best regards,
> Andreas Hindborg
>
> [1] https://lore.kernel.org/r/87v7hdh9m4.fsf@t14s.mail-host-address-is-not-set
I agree. My point was that expire() can be safe only under the same
constraints as forward()/forward_now() so the API should require
Pin<&mut Self> and expose it on HrTimerCallbackContext.
Powered by blists - more mailing lists