Rust for Linux List
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: Gary Guo <gary@garyguo.net>, Gary Guo <gary@garyguo.net>,
	Sang-Heon Jeon <ekffu200098@gmail.com>,
	boqun@kernel.org, fujita.tomonori@gmail.com, frederic@kernel.org,
	lyude@redhat.com, tglx@kernel.org, anna-maria@linutronix.de,
	jstultz@google.com, sboyd@kernel.org
Cc: rust-for-linux@vger.kernel.org
Subject: Re: [PATCH] rust: time: add debug assertions for out-of-range input in fsleep()
Date: Sat, 09 May 2026 19:44:04 +0200	[thread overview]
Message-ID: <87mry85vh7.fsf@t14s.mail-host-address-is-not-set> (raw)
In-Reply-To: <DIE8AGXTZXBL.2RY8JCWNOD2HG@garyguo.net>

"Gary Guo" <gary@garyguo.net> writes:

> 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`.

I actually mixed these up, thanks for pointing that out. We do not have
`warn_once!` yet.

>
>>
>> `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.

Apparently this was discussed in start of April [1] (I somehow missed
it), and as far as I can tell, consensus is that we do not use
`WARN_ONCE`. Instead we use `debug_assert` with `pr_warn_once`. That
sounds reasonable to me.

This can be a combined macro or open coded, either way is fine with me.

I think we should add the `debug_assert` as suggested by this patch, add
the `pr_warn_once` in the not taken branch, and remove the TODO about
`WARN_ONCE`. We can bike-shed a combined macro on the side.

Sounds reasonable @Gary?

Best regards,
Andreas Hindborg


[1] https://lore.kernel.org/r/20260226120848.82891-5-adarshdas950@gmail.com



      reply	other threads:[~2026-05-09 17:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <qBPUAToMpl5CvVd22lUrJOgsVSuqVYKsjEHpbs1UK-VTO-vN8UFOa35fFMsYOHoBuUp9HcP65ljAxmLQMcGS9w==@protonmail.internalid>
2026-05-08 17:38 ` [PATCH] rust: time: add debug assertions for out-of-range input in fsleep() Sang-Heon Jeon
2026-05-09  6:41   ` Onur Özkan
2026-05-09  8:08   ` Andreas Hindborg
2026-05-09 12:10     ` Gary Guo
2026-05-09 14:36       ` Andreas Hindborg
2026-05-09 14:50         ` Gary Guo
2026-05-09 17:44           ` Andreas Hindborg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mry85vh7.fsf@t14s.mail-host-address-is-not-set \
    --to=a.hindborg@kernel.org \
    --cc=anna-maria@linutronix.de \
    --cc=boqun@kernel.org \
    --cc=ekffu200098@gmail.com \
    --cc=frederic@kernel.org \
    --cc=fujita.tomonori@gmail.com \
    --cc=gary@garyguo.net \
    --cc=jstultz@google.com \
    --cc=lyude@redhat.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tglx@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox