Re: Printing with overflow checks can cause modpost errors

[Andrew Ballance <andrewjballance@gmail.com>]

On 9/11/25 9:53 PM, Joel Fernandes wrote:
> On Thu, Sep 11, 2025 at 07:27:26PM -0500, Andrew Ballance wrote:
>> On Thu, Sep 11, 2025 at 05:31:57PM -0400, Joel Fernandes wrote:
>>> Hello,
>>> Recently some of have been running into modpost errors more frequently. Ahead
>>> of Kangrejos, I am trying to study them, the one I looked at today is truly
>>> weird, below are more details.
>>>
>>> I narrowed it down to the print statement and specifically the FFI call to
>>> printk bindings. This was first reported by Timur Tabi on CC.
>>>
>>> With CONFIG_RUST_OVERFLOW_CHECKS=y and CONFIG_RUST_BUILD_ASSERT_ALLOW=y, the
>>> following patch when applied to nova-core will fail to build with following
>>> errors. The question is why does the overflow checking fail since the
>>> arithmetic is valid, and why only during printing (and say not during the
>>> call to write32).
>>>
>>>    MODPOST Module.symvers
>>> ERROR: modpost: "rust_build_error" [drivers/gpu/nova-core/nova_core.ko] undefined!
>>> make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
>>> make[1]: *** [/home/joelaf/repo/linux-nova-rm-call/Makefile:1961: modpost] Error 2
>>> make: *** [Makefile:248: __sub-make] Error 2
>>>
>>> Any comments or thoughts?
>>>
>>
>> Io::write32 tries to do a bounds check at compile time and if it cannot
>> be done it causes a build error. it looks like because a pointer to
>> offset is passed across a ffi boundary, rustc makes no assumptions about
>> the value of offset. so it cannot do the bounds check at compile time
>> and causes a build error.
> 
> Are you saying this issue is related to iowrite32? I don't think so because
> the issue does not happen if you comment out the pr_err in my example and
> leave the write32 as it is. So it is something with the call to printk (FFI).
> 
> Why can't it assume the value of offset? All the values to compute it are
> available at compile time right?
> 
> thanks,
> 
>   - Joel
> 

This is a resend because I forgot to cc the mailing list.

it has to do with the FFI call. The value of offset can be found out at
compile time, but because a pointer is passed through, the c side could
theoretically change the value before write32 is called.
The pointer passed is const so rustc should assume that the c side does
not change offset, but looks like rustc does not do that.

as a test i created a version where a copy of offset is passed to printk
instead of offset and it compiles.
e.g:
// SNIP
let offset = <B as kernel::io::register::RegisterBase<$base>>::BASE
     + Self::OFFSET
     + (idx * Self::STRIDE);
let offset_copy = offset;

pr_err!("{}", offset_copy);
io.write32(self.0, offset);
// SNIP

Best regards,
Andrew Ballance