Re: [PATCH v2 5/5] rust: devres: embed struct devres_node directly

[Alice Ryhl <aliceryhl@google.com>]

On Fri, Feb 13, 2026 at 11:07:15PM +0100, Danilo Krummrich wrote:
> Currently, the Devres<T> container uses devm_add_action() to register a
> devres callback.
> 
> devm_add_action() allocates a struct action_devres, which on top of
> struct devres_node, just keeps a data pointer and release function
> pointer.
> 
> This is an unnecessary indirection, given that analogous to struct
> devres, the Devres<T> container can just embed a struct devres_node
> directly without an additional allocation.
> 
> In contrast to struct devres, we don't need to force an alignment of
> ARCH_DMA_MINALIGN (as struct devres does to account for the worst case)
> since we have generics in Rust. I.e. the compiler already ensures
> correct alignment of the embedded T in Devres<T>.
> 
> Thus, get rid of devm_add_action() and instead embed a struct
> devres_node directly.
> 
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

>  /// This abstraction is meant to be used by subsystems to containerize [`Device`] bound resources to
>  /// manage their lifetime.
>  ///
> @@ -111,12 +124,63 @@
>  /// ```
>  pub struct Devres<T: Send> {
>      dev: ARef<Device>,

Wouldn't it be nicer to move this into the Arc? Most of the time, it
would probably fit in the kmalloc bucket without enlarging it, so it
seems like that would be better for most scenarios.

> +// Calling the FFI functions from the `base` module directly from the `Devres<T>` impl may result in
> +// them being called directly from driver modules. This happens since the Rust compiler will use
> +// monomorphisation, so it might happen that functions are instantiated within the calling driver
> +// module. For now, work around this with `#[inline(never)]` helpers.
> +//
> +// TODO: Remove once a more generic solution has been implemented. For instance, we may be able to
> +// leverage `bindgen` to take care of this depending on whether a symbol is (already) exported.

I'm not sure what a generic solution would look like. There is an
assumption that if A can call B and B can call C, then A can call C.
Other than just exporting the C methods, possibly for Rust only?

What happens in C when you turn on LTO and core kernel methods get
inlined into modules?

> +    #[inline(never)]
> +    #[allow(clippy::missing_safety_doc)]
> +    pub(super) unsafe fn devres_node_remove(
> +        dev: *mut bindings::device,
> +        node: *mut bindings::devres_node,
> +    ) -> bool {

Since you're taking the opportunity to wrap these, I'd consider adding
#[must_use] here.

> +                    // SAFETY: `node` is a valid pointer to an uninitialized `struct devres_node`.
> +                    unsafe {
> +                        base::devres_set_node_dbginfo(
> +                            node,
> +                            // TODO: Use `core::any::type_name::<T>()` once we are able to convert
> +                            // the `&str` to a NULL terminated `&CStr` without additional
> +                            // allocation.
> +                            c"Devres<T>".as_char_ptr(),

The problem is that type_name() is not const. We can convert a const
&str to &CStr with no problems already.

Alice