[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z93io9rkpRMiXEKi@pavilion.home>
Date: Fri, 21 Mar 2025 23:05:23 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: linux-kernel@...r.kernel.org,
Daniel Almeida <daniel.almeida@...labora.com>,
Gary Guo <gary@...yguo.net>, Alice Ryhl <aliceryhl@...gle.com>,
Fiona Behrens <me@...enk.dev>, rust-for-linux@...r.kernel.org,
netdev@...r.kernel.org, andrew@...n.ch, hkallweit1@...il.com,
tmgross@...ch.edu, ojeda@...nel.org, alex.gaynor@...il.com,
bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
a.hindborg@...sung.com, anna-maria@...utronix.de,
tglx@...utronix.de, arnd@...db.de, jstultz@...gle.com,
sboyd@...nel.org, mingo@...hat.com, peterz@...radead.org,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, vschneid@...hat.com, tgunders@...hat.com,
david.laight.linux@...il.com
Subject: Re: [PATCH v11 5/8] rust: time: Add wrapper for fsleep() function
Le Thu, Feb 20, 2025 at 04:06:07PM +0900, FUJITA Tomonori a écrit :
> Add a wrapper for fsleep(), flexible sleep functions in
> include/linux/delay.h which typically deals with hardware delays.
>
> The kernel supports several sleep functions to handle various lengths
> of delay. This adds fsleep(), automatically chooses the best sleep
> method based on a duration.
>
> sleep functions including fsleep() belongs to TIMERS, not
> TIMEKEEPING. They are maintained separately. rust/kernel/time.rs is an
> abstraction for TIMEKEEPING. To make Rust abstractions match the C
> side, add rust/kernel/time/delay.rs for this wrapper.
>
> fsleep() can only be used in a nonatomic context. This requirement is
> not checked by these abstractions, but it is intended that klint [1]
> or a similar tool will be used to check it in the future.
>
> Link: https://rust-for-linux.com/klint [1]
> Tested-by: Daniel Almeida <daniel.almeida@...labora.com>
> Reviewed-by: Gary Guo <gary@...yguo.net>
> Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>
> Reviewed-by: Fiona Behrens <me@...enk.dev>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@...il.com>
Sorry to make a late review. I don't mean to delay that any further
but:
> +/// `delta` must be within `[0, i32::MAX]` microseconds;
> +/// otherwise, it is erroneous behavior. That is, it is considered a bug
> +/// to call this function with an out-of-range value, in which case the function
> +/// will sleep for at least the maximum value in the range and may warn
> +/// in the future.
> +///
> +/// The behavior above differs from the C side [`fsleep()`] for which out-of-range
> +/// values mean "infinite timeout" instead.
And very important: the behaviour also differ in that the C side takes
usecs while this takes nsecs. We should really disambiguate the situation
as that might create confusion or misusage.
Either this should be renamed to fsleep_ns() or fsleep_nsecs(), or this should
take microseconds directly.
Thanks.
> +///
> +/// This function can only be used in a nonatomic context.
> +///
> +/// [`fsleep`]: https://docs.kernel.org/timers/delay_sleep_functions.html#c.fsleep
> +pub fn fsleep(delta: Delta) {
> + // The maximum value is set to `i32::MAX` microseconds to prevent integer
> + // overflow inside fsleep, which could lead to unintentional infinite sleep.
> + const MAX_DELTA: Delta = Delta::from_micros(i32::MAX as i64);
> +
> + let delta = if (Delta::ZERO..=MAX_DELTA).contains(&delta) {
> + delta
> + } else {
> + // TODO: Add WARN_ONCE() when it's supported.
> + MAX_DELTA
> + };
> +
> + // SAFETY: It is always safe to call `fsleep()` with any duration.
> + unsafe {
> + // Convert the duration to microseconds and round up to preserve
> + // the guarantee; `fsleep()` sleeps for at least the provided duration,
> + // but that it may sleep for longer under some circumstances.
> + bindings::fsleep(delta.as_micros_ceil() as c_ulong)
> + }
> +}
> --
> 2.43.0
>
Powered by blists - more mailing lists