Re: [PATCH 2/5] devres: export devres_node_init() and devres_node_add()

[Alice Ryhl]

On Fri, Feb 06, 2026 at 02:22:42PM +0100, Greg KH wrote:
> On Fri, Feb 06, 2026 at 02:16:05PM +0100, Danilo Krummrich wrote:
> > On Fri Feb 6, 2026 at 1:34 PM CET, Greg KH wrote:
> > > That's fine, because the rust driver core code should also be built into
> > > the kernel, not as a module, right?
> > 
> > Yes, but the Rust compiler may still choose to put some of the core code into
> > the module.
> 
> What exactly do you mean by "the module"?
> 
> > Especially with generic types and functions the Rust compiler may move some the
> > generated code for a certain type instance into the module that instanciates the
> > type.
> 
> Ah, that's a mess.  why?  The code lives in the .rs file in the kernel
> core, right?

It might still be inlined into downstream compilation units. Rust has no
equivalent to 'static inline' function in a header file, after all.

> > For instance, even though rust/kernel/devres.rs is *always* built-in, we get the
> > following error when devres_node_init() is not exported when the users of this
> > built-in code are built as module.
> > 
> > 	ERROR: modpost: "devres_node_init" [drivers/pwm/pwm_th1520.ko] undefined!
> > 	ERROR: modpost: "devres_node_init" [drivers/gpu/drm/tyr/tyr.ko] undefined!
> > 	ERROR: modpost: "devres_node_init" [drivers/gpu/nova-core/nova_core.ko] undefined!
> > 	ERROR: modpost: "devres_node_init" [samples/rust/rust_dma.ko] undefined!
> > 	ERROR: modpost: "devres_node_init" [samples/rust/rust_driver_pci.ko] undefined!
> > 	ERROR: modpost: "devres_node_init" [samples/rust/rust_driver_auxiliary.ko] undefined!
> > 	make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> 
> This feels like a compiler bug, how is the compiler reaching into
> devres.rs and sucking out code to put into the module?  Doesn't the
> build/link boundry stay at the .rs boundry?

It's quite intentional.

It used to be the case that only functions marked #[inline] could be
inlined like this, but it was changed so that small functions without
any marker are also eligible for inlining. Now you need #[inline(never)]
to ensure it does not happen.

Note that this analysis only applies to non-generic code. If you call
devres_node_init() from within this function:

impl Devres<T> {
    fn new() -> Self {
        ... devres_node_init() ...
    }
}

then since `new()` is generic over T, it is duplicated for each type T
it is used with (via monomorphisation, like C++ templates). So the
actual `new` function might be instantiated in the crate that uses
Devres<MyDriverType>, and in this case it ends up in the module even
with #[inline(never)].

So you'd need a non-generic Rust function with #[inline(never)] in this
case, and have Devres::<T>::new() call that function.

> > However, sprinkling "raw" EXPORT_SYMBOL_GPL() due to that is not great at all.
> > Hence, we could do something like in [1] instead. I don't know if there are
> > other options that may be better though.
> > 
> > [1] https://lore.kernel.org/all/DG7UR3WWZB4V.2MYMJJH1VDHH@xxxxxxxxxx/
> 
> That's a start, but still messy.  There's no compiler options to prevent
> this "lifting" of the code out of devres.rs?  If not, this is not going
> to be the only problem that drivers run into like this in the future.

Because of how monomorphisation, as-is the code actually lives in the
module to begin with.

And not lifting out code causes issues with super small wrapper
functions around C functions too.

Alice