linux-kernel - Re: [PATCH v1 2/2] rust: Add read_poll_timeout

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: <20250827.091427.1081669324737480994.fujita.tomonori@gmail.com>
Date: Wed, 27 Aug 2025 09:14:27 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: dakr@...nel.org
Cc: fujita.tomonori@...il.com, a.hindborg@...nel.org,
 alex.gaynor@...il.com, ojeda@...nel.org, aliceryhl@...gle.com,
 anna-maria@...utronix.de, bjorn3_gh@...tonmail.com, boqun.feng@...il.com,
 frederic@...nel.org, gary@...yguo.net, jstultz@...gle.com,
 linux-kernel@...r.kernel.org, lossin@...nel.org, lyude@...hat.com,
 rust-for-linux@...r.kernel.org, sboyd@...nel.org, tglx@...utronix.de,
 tmgross@...ch.edu, acourbot@...dia.com, daniel.almeida@...labora.com
Subject: Re: [PATCH v1 2/2] rust: Add read_poll_timeout_atomic function

On Tue, 26 Aug 2025 16:12:44 +0200
"Danilo Krummrich" <dakr@...nel.org> wrote:

> On Thu Aug 21, 2025 at 5:57 AM CEST, FUJITA Tomonori wrote:
>> +pub fn read_poll_timeout_atomic<Op, Cond, T>(
>> +    mut op: Op,
>> +    mut cond: Cond,
>> +    delay_delta: Delta,
>> +    timeout_delta: Delta,
>> +) -> Result<T>
>> +where
>> +    Op: FnMut() -> Result<T>,
>> +    Cond: FnMut(&T) -> bool,
>> +{
>> +    let mut left_ns = timeout_delta.as_nanos();
>> +    let delay_ns = delay_delta.as_nanos();
>> +
>> +    loop {
>> +        let val = op()?;
>> +        if cond(&val) {
>> +            // Unlike the C version, we immediately return.
>> +            // We know the condition is met so we don't need to check again.
>> +            return Ok(val);
>> +        }
>> +
>> +        if left_ns < 0 {
>> +            // Unlike the C version, we immediately return.
>> +            // We have just called `op()` so we don't need to call it again.
>> +            return Err(ETIMEDOUT);
>> +        }
>> +
>> +        if !delay_delta.is_zero() {
>> +            udelay(delay_delta);
>> +            left_ns -= delay_ns;
>> +        }
>> +
>> +        cpu_relax();
>> +        left_ns -= 1;
> 
> How do we know that each iteration costs 1ns? To make it even more obvious, we
> don't control the implementation of cond(). Shouldn't we use ktime for this?

The C version used to use ktime but it has been changed not to:

7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()")

https://lore.kernel.org/all/3d2a2f4e553489392d871108797c3be08f88300b.1685692810.git.geert+renesas@glider.be/

I don’t know if the same problem still exists, but I think we should
follow the C implementation. Usually there’s a good reason behind it,
and it has been working so far.

If we want to do it differently in Rust, maybe we should first discuss
the C implementation.