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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20251026.221126.278291666422815679.fujita.tomonori@gmail.com>
Date: Sun, 26 Oct 2025 22:11:26 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: miguel.ojeda.sandonis@...il.com
Cc: aliceryhl@...gle.com, a.hindborg@...nel.org, 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, 24 Oct 2025 21:05:19 +0200
Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:

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

I've sent v3 with debug_assert! added.

Is anyone currently working on pr_*_once? If I remember correctly,
there were a few proposals in the past, but they didn’t reach a
conclusion on how to implement it and never got merged.