Re: [PATCH] rust: pin-init: add references to previously initialized fields

Re: [PATCH] rust: pin-init: add references to previously initialized fields

[Janne Grunau]

On Sat, Dec 06, 2025 at 09:23:08AM +0100, Benno Lossin wrote:
> On Wed Dec 3, 2025 at 11:05 PM CET, Janne Grunau wrote:
> > On Fri, Sep 05, 2025 at 04:00:46PM +0200, Benno Lossin wrote:
> >> After initializing a field in an initializer macro, create a variable
> >> holding a reference that points at that field. The type is either
> >> `Pin<&mut T>` or `&mut T` depending on the field's structural pinning
> >> kind.
> >
> > just as a heads up: creating references broke part of the agx firmware
> > init structs which uses a `#[repr(C, packed)]` struct as field in
> > another struct. This fails with
> >
> > | error[E0793]: reference to packed field is unaligned
> > |    --> ../drivers/gpu/drm/asahi/initdata.rs:722:28
> > |     |
> > | 722 |                       sub <- try_init!(raw::GlobalsSub::ver {
> > |     |  ____________________________^
> > | 723 | |                         unk_54: cfg.global_unk_54,
> > | 724 | |                         unk_56: 40,
> > | 725 | |                         unk_58: 0xffff,
> > | ...   |
> > | 731 | |                         ..Zeroable::init_zeroed()
> > | 732 | |                     }),
> > |     | |______________________^
> > |     |
> > |     = note: packed structs are only aligned by one byte, and many modern architectures penalize unaligned field accesses
> > |     = note: creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
> > |     = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)
> > |     = note: this error originates in the macro `$crate::__init_internal` which comes from the expansion of the macro `try_init` (in Nightly builds, run with -Z macro-backtrace for more info)
> >
> > This was easy enough to work around, I don't see how this embedding of a
> > `#[repr(C, packed)]` struct was necessary or at least helpful. The code
> > is not expected to be included in the upstream driver so it no worth
> > spending effort on this.
> >
> > I don't think it's likely that anyone else will run into this but I
> > thought I mention it at least.
> >
> > The asahi driver also ran into the discussed variable shadowing issue (a
> > variable was used to initialize a field of the same name and was later
> > used to initialize another field). This was trivially fixed by renaming
> > the variable.
> 
> Thanks for the report, I expected the latter kind of error, but was not
> aware of the packed struct issue. If anyone needs a proper workaround
> from pin-init, let me know.

I spoke too soon. The packed struct issue is also present in the capture
driver for Macbook microphones (aop_audio). Working around this issue
there is less obvious and more effort. I think it might be enough to use
unaligned u32 / u64 types already present in asahi [1].

I'm not sure how prevalent packed structs are outside of Apple's
firmware interfaces. I was surprised running into the same issue in a
second driver but I shouldn't have been. There are plans for another
driver where this isssue will be present.

A workaround on pin-init side would be appreciated. Due to the nature of
these packed structs I do not see a need to have access to previously
initialized fields. An optional way to supress the references would be
good enough for the cases I'm aware off.

Thanks

Janne

1: https://github.com/AsahiLinux/linux/blob/asahi-6.17.9-1/drivers/gpu/drm/asahi/fw/types.rs#L48

Re: [PATCH] rust: pin-init: add references to previously initialized fields

[Benno Lossin]

On Sat Dec 6, 2025 at 6:02 PM CET, Janne Grunau wrote:
> On Sat, Dec 06, 2025 at 09:23:08AM +0100, Benno Lossin wrote:
>> On Wed Dec 3, 2025 at 11:05 PM CET, Janne Grunau wrote:
>> > On Fri, Sep 05, 2025 at 04:00:46PM +0200, Benno Lossin wrote:
>> >> After initializing a field in an initializer macro, create a variable
>> >> holding a reference that points at that field. The type is either
>> >> `Pin<&mut T>` or `&mut T` depending on the field's structural pinning
>> >> kind.
>> >
>> > just as a heads up: creating references broke part of the agx firmware
>> > init structs which uses a `#[repr(C, packed)]` struct as field in
>> > another struct. This fails with
>> >
>> > | error[E0793]: reference to packed field is unaligned
>> > |    --> ../drivers/gpu/drm/asahi/initdata.rs:722:28
>> > |     |
>> > | 722 |                       sub <- try_init!(raw::GlobalsSub::ver {
>> > |     |  ____________________________^
>> > | 723 | |                         unk_54: cfg.global_unk_54,
>> > | 724 | |                         unk_56: 40,
>> > | 725 | |                         unk_58: 0xffff,
>> > | ...   |
>> > | 731 | |                         ..Zeroable::init_zeroed()
>> > | 732 | |                     }),
>> > |     | |______________________^
>> > |     |
>> > |     = note: packed structs are only aligned by one byte, and many modern architectures penalize unaligned field accesses
>> > |     = note: creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
>> > |     = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)
>> > |     = note: this error originates in the macro `$crate::__init_internal` which comes from the expansion of the macro `try_init` (in Nightly builds, run with -Z macro-backtrace for more info)
>> >
>> > This was easy enough to work around, I don't see how this embedding of a
>> > `#[repr(C, packed)]` struct was necessary or at least helpful. The code
>> > is not expected to be included in the upstream driver so it no worth
>> > spending effort on this.
>> >
>> > I don't think it's likely that anyone else will run into this but I
>> > thought I mention it at least.
>> >
>> > The asahi driver also ran into the discussed variable shadowing issue (a
>> > variable was used to initialize a field of the same name and was later
>> > used to initialize another field). This was trivially fixed by renaming
>> > the variable.
>> 
>> Thanks for the report, I expected the latter kind of error, but was not
>> aware of the packed struct issue. If anyone needs a proper workaround
>> from pin-init, let me know.
>
> I spoke too soon. The packed struct issue is also present in the capture
> driver for Macbook microphones (aop_audio). Working around this issue
> there is less obvious and more effort. I think it might be enough to use
> unaligned u32 / u64 types already present in asahi [1].
>
> I'm not sure how prevalent packed structs are outside of Apple's
> firmware interfaces. I was surprised running into the same issue in a
> second driver but I shouldn't have been. There are plans for another
> driver where this isssue will be present.
>
> A workaround on pin-init side would be appreciated. Due to the nature of
> these packed structs I do not see a need to have access to previously
> initialized fields. An optional way to supress the references would be
> good enough for the cases I'm aware off.

FYI, I am merging a workaround this cycle, see [1]. Gary had a good idea
for a future patch series which I am tracking in [2].

Cheers,
Benno

[1]: https://lore.kernel.org/all/20260111122554.2662175-14-lossin@kernel.org
[2]: https://github.com/Rust-for-Linux/pin-init/issues/98

Re: [PATCH] rust: pin-init: add references to previously initialized fields

[Benno Lossin]

On Sun Jan 11, 2026 at 6:06 PM CET, Benno Lossin wrote:
> On Sat Dec 6, 2025 at 6:02 PM CET, Janne Grunau wrote:
>> On Sat, Dec 06, 2025 at 09:23:08AM +0100, Benno Lossin wrote:
>>> On Wed Dec 3, 2025 at 11:05 PM CET, Janne Grunau wrote:
>>> > On Fri, Sep 05, 2025 at 04:00:46PM +0200, Benno Lossin wrote:
>>> >> After initializing a field in an initializer macro, create a variable
>>> >> holding a reference that points at that field. The type is either
>>> >> `Pin<&mut T>` or `&mut T` depending on the field's structural pinning
>>> >> kind.
>>> >
>>> > just as a heads up: creating references broke part of the agx firmware
>>> > init structs which uses a `#[repr(C, packed)]` struct as field in
>>> > another struct. This fails with
>>> >
>>> > | error[E0793]: reference to packed field is unaligned
>>> > |    --> ../drivers/gpu/drm/asahi/initdata.rs:722:28
>>> > |     |
>>> > | 722 |                       sub <- try_init!(raw::GlobalsSub::ver {
>>> > |     |  ____________________________^
>>> > | 723 | |                         unk_54: cfg.global_unk_54,
>>> > | 724 | |                         unk_56: 40,
>>> > | 725 | |                         unk_58: 0xffff,
>>> > | ...   |
>>> > | 731 | |                         ..Zeroable::init_zeroed()
>>> > | 732 | |                     }),
>>> > |     | |______________________^
>>> > |     |
>>> > |     = note: packed structs are only aligned by one byte, and many modern architectures penalize unaligned field accesses
>>> > |     = note: creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
>>> > |     = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)
>>> > |     = note: this error originates in the macro `$crate::__init_internal` which comes from the expansion of the macro `try_init` (in Nightly builds, run with -Z macro-backtrace for more info)
>>> >
>>> > This was easy enough to work around, I don't see how this embedding of a
>>> > `#[repr(C, packed)]` struct was necessary or at least helpful. The code
>>> > is not expected to be included in the upstream driver so it no worth
>>> > spending effort on this.
>>> >
>>> > I don't think it's likely that anyone else will run into this but I
>>> > thought I mention it at least.
>>> >
>>> > The asahi driver also ran into the discussed variable shadowing issue (a
>>> > variable was used to initialize a field of the same name and was later
>>> > used to initialize another field). This was trivially fixed by renaming
>>> > the variable.
>>> 
>>> Thanks for the report, I expected the latter kind of error, but was not
>>> aware of the packed struct issue. If anyone needs a proper workaround
>>> from pin-init, let me know.
>>
>> I spoke too soon. The packed struct issue is also present in the capture
>> driver for Macbook microphones (aop_audio). Working around this issue
>> there is less obvious and more effort. I think it might be enough to use
>> unaligned u32 / u64 types already present in asahi [1].
>>
>> I'm not sure how prevalent packed structs are outside of Apple's
>> firmware interfaces. I was surprised running into the same issue in a
>> second driver but I shouldn't have been. There are plans for another
>> driver where this isssue will be present.
>>
>> A workaround on pin-init side would be appreciated. Due to the nature of
>> these packed structs I do not see a need to have access to previously
>> initialized fields. An optional way to supress the references would be
>> good enough for the cases I'm aware off.
>
> FYI, I am merging a workaround this cycle, see [1]. Gary had a good idea
> for a future patch series which I am tracking in [2].

Update on this situation, we have a problem: packed struct and the
current version of pin-init are unsound, so I'll sadly have to remove
the current workaround attribute. That is because the `[Pin]Init` trait
requires an aligned pointer as the input. Fixing this requires
introducing a new hierarchy for the Init trait that supports misaligned
writes.

If you really require this feature, then we can work something out.
Would you mind giving me a pointer to the code that you're currently
using or that you would like to support?

Cheers,
Benno