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: <7d157605-4c59-4e04-8c41-1f7a4c86b34c@nvidia.com>
Date: Sun, 30 Nov 2025 16:52:09 -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 2:42 PM, Miguel Ojeda wrote:
> 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.

More precisely, it was already *hinted* to be 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.

I'm having a difficult time with that statement, because if you
write:

fn bar(n: usize) {
    build_assert!(n > 1);
    ...
}

Then that is conceptually wrong, because it must be a runtime check.

The only way it can be a compile-time check is if you have some
way to *guarantee* that the function is inlined into code that has
a const n.

Absent such guarantees (and we have "nearly none", right?), we have
been writing "partly wrong" code in all such cases.

Why? Are the guarantees stronger than they look? Or other reasoning?

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

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. 

thanks,
-- 
John Hubbard