Re: [PATCH 6.19.y 2/2] rust: pin-init: replace shadowed return token by `unsafe`-to-create token

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Mar 25, 2026 at 01:57:32PM +0100, Benno Lossin wrote:
> [ Upstream commit fdbaa9d2b78e0da9e1aeb303bbdc3adfe6d8e749 ]
> 
> We use a unit struct `__InitOk` in the closure generated by the
> initializer macros as the return value. We shadow it by creating a
> struct with the same name again inside of the closure, preventing early
> returns of `Ok` in the initializer (before all fields have been
> initialized).
> 
> In the face of Type Alias Impl Trait (TAIT) and the next trait solver,
> this solution no longer works [1]. The shadowed struct can be named
> through type inference. In addition, there is an RFC proposing to add
> the feature of path inference to Rust, which would similarly allow [2].
> 
> Thus remove the shadowed token and replace it with an `unsafe` to create
> token.
> 
> The reason we initially used the shadowing solution was because an
> alternative solution used a builder pattern. Gary writes [3]:
> 
>     In the early builder-pattern based InitOk, having a single InitOk
>     type for token is unsound because one can launder an InitOk token
>     used for one place to another initializer. I used a branded lifetime
>     solution, and then you figured out that using a shadowed type would
>     work better because nobody could construct it at all.
> 
> The laundering issue does not apply to the approach we ended up with
> today.
> 
> With this change, the example by Tim Chirananthavat in [1] no longer
> compiles and results in this error:
> 
>     error: cannot construct `pin_init::__internal::InitOk` with struct literal syntax due to private fields
>       --> src/main.rs:26:17
>        |
>     26 |                 InferredType {}
>        |                 ^^^^^^^^^^^^
>        |
>        = note: private field `0` that was not provided
>     help: you might have meant to use the `new` associated function
>        |
>     26 -                 InferredType {}
>     26 +                 InferredType::new()
>        |
> 
> Applying the suggestion of using the `::new()` function, results in
> another expected error:
> 
>     error[E0133]: call to unsafe function `pin_init::__internal::InitOk::new` is unsafe and requires unsafe block
>       --> src/main.rs:26:17
>        |
>     26 |                 InferredType::new()
>        |                 ^^^^^^^^^^^^^^^^^^^ call to unsafe function
>        |
>        = note: consult the function's documentation for information on how to avoid undefined behavior
> 
> Reported-by: Tim Chirananthavat <theemathas@gmail.com>
> Link: https://github.com/rust-lang/rust/issues/153535 [1]
> Link: https://github.com/rust-lang/rfcs/pull/3444#issuecomment-4016145373 [2]
> Link: https://github.com/rust-lang/rust/issues/153535#issuecomment-4017620804 [3]
> Fixes: fc6c6baa1f40 ("rust: init: add initialization macros")
> Cc: stable@vger.kernel.org
> Signed-off-by: Benno Lossin <lossin@kernel.org>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Link: https://patch.msgid.link/20260311105056.1425041-1-lossin@kernel.org
> [ Added period as mentioned. - Miguel ]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> [ Moved to declarative macro, because 6.19.y and earlier do not have
>   `syn`. - Benno ]
> Signed-off-by: Benno Lossin <lossin@kernel.org>

This commit blows up the build for me with lots of errors like:

error[E0433]: failed to resolve: could not find `init` in `$crate`
   --> rust/kernel/maple_tree.rs:393:20
    |
393 |           let tree = pin_init!(MapleTree {
    |  ____________________^
394 | |             // SAFETY: This initializes a maple tree into a pinned slot. The maple tree will be
395 | |             // destroyed in Drop before the memory location becomes invalid.
396 | |             tree <- Opaque::ffi_init(|slot| unsafe {
...   |
399 | |             _p: PhantomData,
400 | |         });
    | |__________^ could not find `init` in `$crate`
    |
    = note: this error originates in the macro `$crate::__init_internal` which comes from the expansion of the macro `pin_init` (in Nightly builds, run with -Z macro-backtrace for more info)



So I'll take patch 1 here, but not this one :(

thanks,

greg k-h