linux-kernel - Re: [PATCH v2 1/2] rust: add udelay() function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANiq72=wkL_tfmStR1HYOBsyV5_o41YXTtUsCM5t+i80+urxxw@mail.gmail.com>
Date: Fri, 24 Oct 2025 21:05:19 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Andreas Hindborg <a.hindborg@...nel.org>, FUJITA Tomonori <fujita.tomonori@...il.com>, dakr@...nel.org, 
	daniel.almeida@...labora.com, alex.gaynor@...il.com, ojeda@...nel.org, 
	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, gregkh@...uxfoundation.org
Subject: Re: [PATCH v2 1/2] rust: add udelay() function

On Fri, Oct 24, 2025 at 11:27 AM Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> For range checks, seemingly unrelated code changes turn out to affect
> these optimizations and break the code.

Most of these calls use constants, so in those cases it would be fine
(and otherwise it is really an issue on the optimizer).

But, yes, using `build_assert!` on the "normal" version of `udelay()`
will eventually surprise someone, because someone out there will start
using it with runtime values that happen to work and that later may
not when code gets shuffled around, especially given it shares the
name with C.

So for functions that do `build_assert!` on parameters we may want at
least a suffix with a particular word (e.g. `_const`) or similar, so
that it is clear calling them may have issues if not "obviously
constant for the optimizer", leaving the "normal" name for the runtime
one or the const generics one etc.

Here, I would suggest we do what we did for `fsleep()` and likely move
both to `debug_assert!` plus `pr_warn!` (and likely `pr_warn_once!`
when supported).

Hopefully we will get soon enough const generics that are flexible
enough -- but passing primitives seems bad here, we want the `Delta`.
So we may want the `udelay_const()` here still.

It pains me a bit that the common case would have the longer name, but
such is life.

Cheers,
Miguel