[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DCCJ26K4TBEG.5HLYXY68Y6QJ@kernel.org>
Date: Tue, 26 Aug 2025 19:15:42 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Daniel Almeida" <daniel.almeida@...labora.com>
Cc: "FUJITA Tomonori" <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>
Subject: Re: [PATCH v1 2/2] rust: Add read_poll_timeout_atomic function
On Tue Aug 26, 2025 at 6:59 PM CEST, Daniel Almeida wrote:
>
>
>> On 26 Aug 2025, at 11:12, 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?
>
> I don’t think ktime can be used from an atomic context?
There's no problem calling things like ktime_get() from atomic context.
Powered by blists - more mailing lists