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

Message-ID: <CANiq72mhXajwj7HjiW_HQq9nO4o-HwBFUya3wjT8pRkWx3xjZw@mail.gmail.com>
Date: Sun, 30 Nov 2025 23:42:41 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: John Hubbard <jhubbard@...dia.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 Sun, Nov 30, 2025 at 11:01 PM John Hubbard <jhubbard@...dia.com> wrote:
>
> It seems pretty clear that if one writes a *build* assertion about
> a function argument, then that is just conceptually wrong unless it
> is inlined. Because it can only really be a run-time assertion.
>
> This is what Alex pointed out, and looking at the code I agree.

No, the function here was already inline.

What Alexandre wrote, which is correct, is that the fix is about
asking for *more* inlining.

The build assertion itself is fine. What is "wrong" is that the
inlining wasn't enough.

Nevertheless, it is (or at least some of these are) definitely a "fix"
in the sense that it did fix cases we hit where the inlining wasn't
enough, like Clippy ones which may change codegen (which in turn is
why we say it cannot be used in "production" kernel builds:
https://github.com/rust-lang/rust-clippy/pull/8037 -- back then it
disabled MIR optimizations).

Cheers,
Miguel