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: <DEO995E7PYDL.WLIHRO9TPA7P@nvidia.com>
Date: Wed, 03 Dec 2025 12:18:34 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Edwin Peer" <epeer@...dia.com>, "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>
Cc: <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 Tue Dec 2, 2025 at 4:53 AM JST, Edwin Peer wrote:
> On 11/27/25 18:11, Alexandre Courbot wrote:
>
>> `build_assert` relies on the compiler to optimize out its error path,
>> lest build fails with the dreaded error:
>>
>>     ERROR: modpost: "rust_build_error" [path/to/module.ko] undefined!
>>
>> It has been observed that very trivial code performing I/O accesses
>> (sometimes even using an immediate value) would seemingly randomly fail
>> with this error whenever `CLIPPY=1` was set. The same behavior was also
>> observed until different, very similar conditions [1][2].
>>
>> The cause appears to be that the failing function is eventually using
>> `build_assert` with its argument, but is only annotated with
>> `#[inline]`. This gives the compiler freedom to not inline the function,
>> which it notably did when Clippy was active, triggering the error.
>>
>> The fix is to annotate functions passing their argument to
>> `build_assert` with `#[inline(always)]`, telling the compiler to be as
>> aggressive as possible with their inlining. This is also the correct
>> behavior as inlining is mandatory for correct behavior in these cases.
>>
>> Add a paragraph instructing to annotate such functions with
>> `#[inline(always)]` in `build_assert`'s documentation, and split its
>> example to illustrate.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@...dia.com>
>> ---
>>  rust/kernel/build_assert.rs | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/rust/kernel/build_assert.rs b/rust/kernel/build_assert.rs
>> index 6331b15d7c4d..f8124dbc663f 100644
>> --- a/rust/kernel/build_assert.rs
>> +++ b/rust/kernel/build_assert.rs
>> @@ -61,8 +61,13 @@ macro_rules! build_error {
>>  ///     build_assert!(N > 1); // Build-time check
>>  ///     assert!(N > 1); // Run-time check
>>  /// }
>> +/// ```
>>  ///
>> -/// #[inline]
>> +/// When a condition depends on a function argument, the function must be annotated with
>> +/// `#[inline(always)]`. Without this attribute, the compiler may choose to not inline the
>> +/// function, preventing it from optimizing out the error path.
>> +/// ```
>> +/// #[inline(always)]
>
> The compiler may still choose to not inline the function, even under
> `#[inline(always)]`:
>
> "#[inline(always)] suggests that inline expansion should always be
> performed." [1] 
>
> "Note: In every form the attribute is a hint. The compiler may ignore
> it." [also 1]

This is true, but AFAICT this is the best we can do as of today (and in
practice it thankfully never failed so far). If there is a more reliable
way to always inline functions we should definitely use that though.