When a field has been initialized, `init!`/`pin_init!` create a reference
or pinned reference to the field so it can be accessed later during the
initialization of other fields. However, the reference it created is
incorrectly `&'static` rather than just the scope of the initializer.

This means that you can do

    init!(Foo {
        a: 1,
        _: {
            let b: &'static u32 = a;
        }
    })

which is unsound.

This series fix the issue. Details can be found in the second patch.

---
Changes in v3:
- Reworked `DropGuard` to still use pointers and related safety comments
  (Sashiko).
- Link to v2: https://patch.msgid.link/20260423-pin-init-fix-v2-0-ee3081093a0e@garyguo.net

Changes in v2:
- Moved the field alignment check as the current dual-purpose reference taking
  for guard and for unaligned fields cause trouble when refactoring.
- Use a method instead of `DerefMut` operator as we don't need the `Deref`.
- Reworked `DropGuard` to use a reference to capture the safety invariants
  (Sashiko)
- Generally improved the safety comments.
- Link to v1: https://lore.kernel.org/rust-for-linux/20260420172302.1843752-1-gary@kernel.org

---
Gary Guo (2):
      rust: pin-init: internal: move alignment check to `make_field_check`
      rust: pin-init: fix incorrect accessor reference lifetime

 rust/pin-init/internal/src/init.rs | 184 +++++++++++++++++--------------------
 rust/pin-init/src/__internal.rs    |  28 ++++--
 2 files changed, 103 insertions(+), 109 deletions(-)
---
base-commit: 97e797263a5e963da3d1e66e743fd518567dfe37
change-id: 20260423-pin-init-fix-cf469cd6f782

Best regards,
--  
Gary Guo <gary@garyguo.net>

On Mon, Apr 27, 2026 at 5:43 PM Gary Guo <gary@garyguo.net> wrote:
>
> When a field has been initialized, `init!`/`pin_init!` create a reference
> or pinned reference to the field so it can be accessed later during the
> initialization of other fields. However, the reference it created is
> incorrectly `&'static` rather than just the scope of the initializer.
>
> This means that you can do
>
>     init!(Foo {
>         a: 1,
>         _: {
>             let b: &'static u32 = a;
>         }
>     })
>
> which is unsound.
>
> This series fix the issue. Details can be found in the second patch.

Applied to `rust-fixes` (originally, half a day ago) -- thanks!

There are a couple typos in the contents of #2, but I didn't change
them since I imagine you may want to do that upstream (relinguished,
transfer -> transfers). I only fixed a couple nits in the commit
messages since I assume that has no impact on your processes:

    [ Reworded for missing word. - Miguel ]

    [ Reworded for typo. - Miguel ]

Cheers,
Miguel

On Thu Apr 30, 2026 at 9:44 PM BST, Miguel Ojeda wrote:
> On Mon, Apr 27, 2026 at 5:43 PM Gary Guo <gary@garyguo.net> wrote:
>>
>> When a field has been initialized, `init!`/`pin_init!` create a reference
>> or pinned reference to the field so it can be accessed later during the
>> initialization of other fields. However, the reference it created is
>> incorrectly `&'static` rather than just the scope of the initializer.
>>
>> This means that you can do
>>
>>     init!(Foo {
>>         a: 1,
>>         _: {
>>             let b: &'static u32 = a;
>>         }
>>     })
>>
>> which is unsound.
>>
>> This series fix the issue. Details can be found in the second patch.
>
> Applied to `rust-fixes` (originally, half a day ago) -- thanks!
>
> There are a couple typos in the contents of #2, but I didn't change
> them since I imagine you may want to do that upstream (relinguished,
> transfer -> transfers). I only fixed a couple nits in the commit
> messages since I assume that has no impact on your processes:
>
>     [ Reworded for missing word. - Miguel ]
>
>     [ Reworded for typo. - Miguel ]

For this specific one it would be okay even if you fixed up the typos, as I
haven't merged the PR yet (I hold up merging just in case you modify the
commit).

Best,
Gary

On Fri, May 1, 2026 at 2:26 AM Gary Guo <gary@garyguo.net> wrote:
>
> For this specific one it would be okay even if you fixed up the typos, as I
> haven't merged the PR yet (I hold up merging just in case you modify the
> commit).

There is no linux-next tree until Monday, so up to you!

Cheers,
Miguel

On Fri May 1, 2026 at 4:56 PM BST, Miguel Ojeda wrote:
> On Fri, May 1, 2026 at 2:26 AM Gary Guo <gary@garyguo.net> wrote:
>>
>> For this specific one it would be okay even if you fixed up the typos, as I
>> haven't merged the PR yet (I hold up merging just in case you modify the
>> commit).
>
> There is no linux-next tree until Monday, so up to you!

I've already merged the PR ~3 hours ago, so it's too late now :)

Best,
Gary