[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <47201640-6655-4F81-BBD6-3E7D6CFD2266@collabora.com>
Date: Fri, 28 Nov 2025 11:02:17 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Danilo Krummrich <dakr@...nel.org>,
Alice Ryhl <aliceryhl@...gle.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 0/7] rust: build_assert: document and fix use with
function arguments
> On 27 Nov 2025, at 23:11, Alexandre Courbot <acourbot@...dia.com> 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, as pointed out by Gary Guo [3], 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.
>
> This series fixes all possible points of failure in the kernel crate,
> and adds documentation to `build_assert` explaining how to properly
> inline functions for which this behavior may arise.
>
> [1] https://lore.kernel.org/all/DEEUYUOAEZU3.1J1HM2YQ10EX1@nvidia.com/
> [2] https://lore.kernel.org/all/A1A280D4-836E-4D75-863E-30B1C276C80C@collabora.com/
> [3] https://lore.kernel.org/all/20251121143008.2f5acc33.gary@garyguo.net/
>
> Signed-off-by: Alexandre Courbot <acourbot@...dia.com>
> ---
> Changes in v2:
> - Turn into a series and address other similar cases in the kernel crate.
> - Link to v1: https://patch.msgid.link/20251127-io-build-assert-v1-1-04237f2e5850@nvidia.com
>
> ---
> Alexandre Courbot (7):
> rust: build_assert: add instructions for use with function arguments
> rust: io: always inline functions using build_assert with arguments
> rust: cpufreq: always inline functions using build_assert with arguments
> rust: bits: always inline functions using build_assert with arguments
> rust: sync: refcount: always inline functions using build_assert with arguments
> rust: irq: always inline functions using build_assert with arguments
> rust: num: bounded: add missing comment for always inlined function
>
> rust/kernel/bits.rs | 6 ++++--
> rust/kernel/build_assert.rs | 7 ++++++-
> rust/kernel/cpufreq.rs | 2 ++
> rust/kernel/io.rs | 9 ++++++---
> rust/kernel/io/resource.rs | 2 ++
> rust/kernel/irq/flags.rs | 2 ++
> rust/kernel/num/bounded.rs | 1 +
> rust/kernel/sync/refcount.rs | 3 ++-
> 8 files changed, 25 insertions(+), 7 deletions(-)
> ---
> base-commit: 54e3eae855629702c566bd2e130d9f40e7f35bde
> change-id: 20251127-io-build-assert-3579a5bfb81c
>
> Best regards,
> --
> Alexandre Courbot <acourbot@...dia.com>
>
Thanks for fixing this. I was _very_ confused when it happened to me.
Reviewed-by: Daniel Almeida <daniel.almeida@...labora.com>
Powered by blists - more mailing lists