[PATCH v2 0/7] rust: build_assert: document and fix use with function arguments

Alexandre Courbot posted 7 patches 3 days, 18 hours ago
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(-)
[PATCH v2 0/7] rust: build_assert: document and fix use with function arguments
Posted by Alexandre Courbot 3 days, 18 hours ago
`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@nvidia.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@nvidia.com>
Re: [PATCH v2 0/7] rust: build_assert: document and fix use with function arguments
Posted by Daniel Almeida 3 days, 6 hours ago

> On 27 Nov 2025, at 23:11, Alexandre Courbot <acourbot@nvidia.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@nvidia.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@nvidia.com>
> 

Thanks for fixing this. I was _very_ confused when it happened to me.

Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Re: [PATCH v2 0/7] rust: build_assert: document and fix use with function arguments
Posted by Daniel Almeida 1 day, 4 hours ago

> On 27 Nov 2025, at 23:11, Alexandre Courbot <acourbot@nvidia.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@nvidia.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@nvidia.com>
> 
> 

Ah, should this have a Fixes: tag?

— Daniel
Re: [PATCH v2 0/7] rust: build_assert: document and fix use with function arguments
Posted by Miguel Ojeda 1 day, 3 hours ago
On Sun, Nov 30, 2025 at 5:09 PM Daniel Almeida
<daniel.almeida@collabora.com> wrote:
>
> Ah, should this have a Fixes: tag?

Yes for those that trigger an error, e.g. the `Bounded` one with -Os
in mainline soon. We probably want Cc: stable@ too -- it is not too
risky to add these anyway.

However, the tag should be different for each commit depending on
where each method was introduced. #1 and #7 are not really fixes, so
they don't need it.

Cheers,
Miguel