[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250117.185501.1171065234025373111.fujita.tomonori@gmail.com>
Date: Fri, 17 Jan 2025 18:55:01 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: aliceryhl@...gle.com
Cc: fujita.tomonori@...il.com, linux-kernel@...r.kernel.org,
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, gary@...yguo.net, bjorn3_gh@...tonmail.com,
benno.lossin@...ton.me, a.hindborg@...sung.com, anna-maria@...utronix.de,
frederic@...nel.org, 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
Subject: Re: [PATCH v8 4/7] rust: time: Add wrapper for fsleep function
On Fri, 17 Jan 2025 10:13:08 +0100
Alice Ryhl <aliceryhl@...gle.com> wrote:
> On Fri, Jan 17, 2025 at 10:01 AM FUJITA Tomonori
> <fujita.tomonori@...il.com> wrote:
>>
>> On Fri, 17 Jan 2025 16:53:26 +0900 (JST)
>> FUJITA Tomonori <fujita.tomonori@...il.com> wrote:
>>
>> > On Thu, 16 Jan 2025 10:27:02 +0100
>> > Alice Ryhl <aliceryhl@...gle.com> wrote:
>> >
>> >>> +/// This function can only be used in a nonatomic context.
>> >>> +pub fn fsleep(delta: Delta) {
>> >>> + // The argument of fsleep is an unsigned long, 32-bit on 32-bit architectures.
>> >>> + // Considering that fsleep rounds up the duration to the nearest millisecond,
>> >>> + // set the maximum value to u32::MAX / 2 microseconds.
>> >>> + const MAX_DURATION: Delta = Delta::from_micros(u32::MAX as i64 >> 1);
>> >>
>> >> Hmm, is this value correct on 64-bit platforms?
>> >
>> > You meant that the maximum can be longer on 64-bit platforms? 2147484
>> > milliseconds is long enough for fsleep's duration?
>> >
>> > If you prefer, I use different maximum durations for 64-bit and 32-bit
>> > platforms, respectively.
>>
>> How about the following?
>>
>> const MAX_DURATION: Delta = Delta::from_micros(usize::MAX as i64 >> 1);
>
> Why is there a maximum in the first place? Are you worried about
> overflow on the C side?
Yeah, Boqun is concerned that an incorrect input (a negative value or
an overflow on the C side) leads to unintentional infinite sleep:
https://lore.kernel.org/lkml/ZxwVuceNORRAI7FV@Boquns-Mac-mini.local/
Powered by blists - more mailing lists