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

["Gary Guo" <gary@garyguo.net>]

On Tue Mar 31, 2026 at 11:17 AM BST, Greg KH wrote:
> 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 :(

This was dicussed in a RfL call, and we think it's fine to not backport this
specific patch.

The soundness issue that this patch is fixing relies on code deliberately
triggering this, a future Rust compiler that enables path inference without
feature gates, and people using that compiler to build an old LTS/stable kernel.

On the other hand, the other two (or 1 for recent enough stable versions)
patches have known broken out-of-tree users. So it's good that they're
backported as code could have relied on them by accident.

Best,
Gary

>
> thanks,
>
> greg k-h