Re: [PATCH] rust: print: Fix issue with rust_build_error

[Joel Fernandes <joelagnelf@nvidia.com>]

On Sat, Sep 20, 2025 at 10:09:30PM +0200, Benno Lossin wrote:
> On Sat Sep 20, 2025 at 6:19 PM CEST, Joel Fernandes wrote:
> > When printing just before calling io.write32(), modpost fails due to
> > build_assert's missing rust_build_error symbol. The issue is that, the
> > printk arguments are passed as reference in bindings code, thus Rust
> > cannot trust its value and fails to optimize away the build_assert.
> >
> > The issue can be reproduced with the following simple snippet:
> >   let offset = 0;
> >   pr_err!("{}", offset);
> >   io.write32(base, offset);
> 
> I took a long time to understand this and I think I got it now, but
> maybe I'm still wrong: passing `offset` to `printk` via a reference
> results in the compiler thinking that the value of `offset` might be
> changed (even though its a shared reference I assume). For this reason
> the `build_assert!` used by `io.write32` cannot be optimized away.

Yes, that's correct and that's my understanding. I in fact also dumped the IR
and see that the compiler is trying to reload the pointer to the offset. I
feel this is a compiler bug, and for immutable variables, the compiler should
not be reloading them even if they are passed to external code? Because if
external code is modifying immutable variables, that is buggy anyway.

> > Fix it by just using a closure to call printk. Rust captures the
> > arguments into the closure's arguments thus breaking the dependency.
> > This can be fixed by simply creating a variable alias for each variable
> > however the closure is a simple and concise fix.
> 
> I don't think this is the fix we want to have.

Yeah its ugly, though a small workaround. IMO ideally the fix should be in
the compiler. I want to send a proposal for this in fact. I looked at the MIR
and I believe with my limited understanding, that the MIR should be issuing a
copy before making a pointer of the immutable variable if pointers to
immutable variables are being passed to external functions.

If I were to send a proposal to the Rust language to start a discussion
leading to a potential RFC stage, would you mind guiding me on doing so?

> In fact it already
> doesn't compile all of the existing code:

Oh gosh, I should have run doctests. I just did a normal build. Let me see
if I can fix this closure issue.

> 
>     error[E0277]: the `?` operator can only be used in a closure that returns `Result` or `Option` (or another type that implements `FromResidual`)
>         --> rust/doctests_kernel_generated.rs:3446:70
>          |
>     3446 |     pr_info!("The frequency at index 0 is: {:?}\n", table.freq(index)?);
>          |     -----------------------------------------------------------------^-
>          |     |                                                                |
>          |     |                                                                cannot use the `?` operator in a closure that returns `()`
>          |     this function should return `Result` or `Option` to accept `?`
> 
> (originating from `rust/kernel/cpufreq.rs:217`)
> 
> Can't we just mark the pointer properly as read-only?

I found no way yet to do that. If there is something you'd like me to try,
let me know. But even if the pointer is a C const pointer, LLVM seems to
always want to reload it.

Thanks!

 - Joel


> 
> ---
> Cheers,
> Benno
> 
> > Another approach with using const-generics for the io.write32 API was
> > investigated, but it cannot work with code that dynamically calculates
> > the write offset.
> >
> > Disassembly of users of pr_err!() with/without patch shows identical
> > code generation, thus the fix has no difference in the final binary.
> >
> > Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>