Re: [PATCH] rust: time: add debug assertions for out-of-range input in fsleep()

["Gary Guo" <gary@garyguo.net>]

On Sat May 9, 2026 at 3:36 PM BST, Andreas Hindborg wrote:
> "Gary Guo" <gary@garyguo.net> writes:
>
>> On Sat May 9, 2026 at 9:08 AM BST, Andreas Hindborg wrote:
>>> "Sang-Heon Jeon" <ekffu200098@gmail.com> writes:
>>>
>>>> fsleep() documents out-of-range input as a bug but does not check
>>>> it, unlike udelay(). Add `debug_assert!` calls to catch it in
>>>> debug builds.
>>>>
>>>> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
>>>> ---
>>>> Hello,
>>>>
>>>> I found this small inconsistency while reading the code. The same
>>>> check was applied to udelay() [1] but does not seem to have been
>>>> extended to fsleep(). Please let me know if I have misunderstood
>>>> anything.
>>>>
>>>> [1] https://lore.kernel.org/all/20251103112958.2961517-2-fujita.tomonori@gmail.com
>>>>
>>>> Best Regards,
>>>> Sang-Heon Jeon
>>>
>>> Looks good to me. Could you add the warn_once and remove the todo as
>>> well? And add the warn_once to udelay as well, so both functions have
>>> same shape.
>>
>> If `warn_once` is added then the debug assert would be unnecessary.
>
> It is different mechanisms in different situations, right?
> `pr_warn_once` prints a warning once (and a stack trace depending on
> kernel configuration?). It would be enabled in production environments,
> and it allows the thread to continue executing after triggering.

The existing comment and your message says `warn_once`, not `pr_warn_once`.

>
> `debug_assert` panics when debug assertions are enabled, otherwise is
> compiled out.
>
> I don't think one makes the other unnecessary.

I don't think there should be two checks of the same thing. Even if we want
different behaviour depending on if debug assertions are enabled or not, it
should be a single macro that switches behaviour based on that config.

Best,
Gary