linux-kernel - Re: [PATCH v2 1/7] rust: build_assert: add instructions for use with function arguments

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: <ea455598-fc0e-4768-b540-5091f7ccd025@nvidia.com>
Date: Sun, 30 Nov 2025 20:36:23 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Alexandre Courbot <acourbot@...dia.com>,
 Danilo Krummrich <dakr@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Trevor Gross <tmgross@...ch.edu>, "Rafael J. Wysocki" <rafael@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>, Will Deacon <will@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, Mark Rutland <mark.rutland@....com>,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 1/7] rust: build_assert: add instructions for use with
 function arguments

On 11/30/25 7:44 PM, Miguel Ojeda wrote:
> On Mon, Dec 1, 2025 at 1:52 AM John Hubbard <jhubbard@...dia.com> wrote:
>>
>> More precisely, it was already *hinted* to be inline.
> 
> By inline I mean it is marked `#[inline]`, which may or may not get
> inlined, but it also has other implications, e.g. codegen can get
> delayed even if there are no callers and is concrete.
> 
>> Then that is conceptually wrong, because it must be a runtime check.
> 
> No, it is not true it must be a runtime check -- it depends: you can
> use such a function in some cases just fine.
> 
> That is the point of `build_assert!`, after all.

This seems strange: something called build_assert!() should not be
put in places where it might not be possible to verify at build-time.
It's built right into the name.

> 
>> Sorry for the fussy detailed questioning here. I'm trying to bottom
>> out here because CLIPPY=1 is a very solid requirement before posting
>> patches.
> 
> No worries, but I don't follow what you mean here. `CLIPPY=1` is still
> required to be clean etc.
> 

CLIPPY=1 is effectively part of the developers' tool chain. It is also
one of the ways to break the build_assert!() call sites.

So now we have to go around and annotate the functions that *contain*
uses of build_assert!(). Otherwise we end up with an unreliable tool
chain for developers. This is not where we should want to be, in the
long run.

Is there proc macro magic we can come up with? Or rustc or clippy
changes? So that this is becomes a better foundation upon which to
build?

thanks,
-- 
John Hubbard