* [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors
[not found] <20260228113713.1402110-1-lossin@kernel.org>
@ 2026-02-28 11:37 ` Benno Lossin
2026-02-28 11:55 ` Gary Guo
2026-02-28 14:11 ` Miguel Ojeda
0 siblings, 2 replies; 5+ messages in thread
From: Benno Lossin @ 2026-02-28 11:37 UTC (permalink / raw)
To: Benno Lossin, Gary Guo, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Wedson Almeida Filho
Cc: stable, rust-for-linux, linux-kernel
We cannot support packed structs without significant changes [1]. The
field accessors ensure that the compiler emits an error if one tries to
create an initializer for a packed struct.
Link: https://github.com/Rust-for-Linux/pin-init/issues/112 [1]
Fixes: 90e53c5e70a6 ("rust: add pin-init API core")
Cc: stable@vger.kernel.org # needed in 6.19, 6.18, 6.17, 6.16, 6.12, 6.6. see below the `---` for more info
Signed-off-by: Benno Lossin <lossin@kernel.org>
---
As already explained in the previous email, we discovered an unsoundness
in pin-init that exists since the beginning, but was unknowingly fixed
in commit 42415d163e5d ("rust: pin-init: add references to previously
initialized fields").
We introduced pin-init in 90e53c5e70a6 ("rust: add pin-init API core"),
which was included in 6.4. The affected stable trees that are still
maintained are: 6.17, 6.16, 6.12, and 6.6. Note that 6.18 and 6.19
already contain 42415d163e5d, so they are unaffected.
We still should backport this piece of documentation explaining the need
for the field accessors for soundness. For this reasons we also want to
backport it to 6.18 and 6.19.
Note that this patch depends on 42415d163e5d; so the only versions this
patch can go in directly are 6.18 and 6.19. I will send separate patch
series' for the older versions. The series' will include a backport of
42415d163e5d as well as this patch, since this patch depends on the
`syn` rewrite, which is not present in older versions.
---
rust/pin-init/internal/src/init.rs | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/rust/pin-init/internal/src/init.rs b/rust/pin-init/internal/src/init.rs
index da53adc44ecf..533029d53d30 100644
--- a/rust/pin-init/internal/src/init.rs
+++ b/rust/pin-init/internal/src/init.rs
@@ -251,6 +251,11 @@ fn init_fields(
});
// Again span for better diagnostics
let write = quote_spanned!(ident.span()=> ::core::ptr::write);
+ // NOTE: the field accessor ensures that the initialized struct is not
+ // `repr(packed)`. If it were, the compiler would emit E0793. We do not support
+ // packed structs, since `Init::__init` requires an aligned pointer; the same
+ // requirement that the call to `ptr::write` below has.
+ // For more info see <https://github.com/Rust-for-Linux/pin-init/issues/112>
let accessor = if pinned {
let project_ident = format_ident!("__project_{ident}");
quote! {
@@ -278,6 +283,11 @@ fn init_fields(
InitializerKind::Init { ident, value, .. } => {
// Again span for better diagnostics
let init = format_ident!("init", span = value.span());
+ // NOTE: the field accessor ensures that the initialized struct is not
+ // `repr(packed)`. If it were, the compiler would emit E0793. We do not support
+ // packed structs, since `Init::__init` requires an aligned pointer; the same
+ // requirement that the call to `ptr::write` below has.
+ // For more info see <https://github.com/Rust-for-Linux/pin-init/issues/112>
let (value_init, accessor) = if pinned {
let project_ident = format_ident!("__project_{ident}");
(
--
2.53.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors
2026-02-28 11:37 ` [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors Benno Lossin
@ 2026-02-28 11:55 ` Gary Guo
2026-02-28 14:56 ` Benno Lossin
2026-02-28 14:11 ` Miguel Ojeda
1 sibling, 1 reply; 5+ messages in thread
From: Gary Guo @ 2026-02-28 11:55 UTC (permalink / raw)
To: Benno Lossin, Gary Guo, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Wedson Almeida Filho
Cc: stable, rust-for-linux, linux-kernel
On Sat Feb 28, 2026 at 11:37 AM GMT, Benno Lossin wrote:
> We cannot support packed structs without significant changes [1]. The
> field accessors ensure that the compiler emits an error if one tries to
> create an initializer for a packed struct.
>
> Link: https://github.com/Rust-for-Linux/pin-init/issues/112 [1]
> Fixes: 90e53c5e70a6 ("rust: add pin-init API core")
> Cc: stable@vger.kernel.org # needed in 6.19, 6.18, 6.17, 6.16, 6.12, 6.6. see below the `---` for more info
> Signed-off-by: Benno Lossin <lossin@kernel.org>
> ---
> As already explained in the previous email, we discovered an unsoundness
> in pin-init that exists since the beginning, but was unknowingly fixed
> in commit 42415d163e5d ("rust: pin-init: add references to previously
> initialized fields").
>
> We introduced pin-init in 90e53c5e70a6 ("rust: add pin-init API core"),
> which was included in 6.4. The affected stable trees that are still
> maintained are: 6.17, 6.16, 6.12, and 6.6. Note that 6.18 and 6.19
> already contain 42415d163e5d, so they are unaffected.
>
> We still should backport this piece of documentation explaining the need
> for the field accessors for soundness. For this reasons we also want to
> backport it to 6.18 and 6.19.
>
> Note that this patch depends on 42415d163e5d; so the only versions this
> patch can go in directly are 6.18 and 6.19. I will send separate patch
> series' for the older versions. The series' will include a backport of
> 42415d163e5d as well as this patch, since this patch depends on the
> `syn` rewrite, which is not present in older versions.
> ---
> rust/pin-init/internal/src/init.rs | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/rust/pin-init/internal/src/init.rs b/rust/pin-init/internal/src/init.rs
> index da53adc44ecf..533029d53d30 100644
> --- a/rust/pin-init/internal/src/init.rs
> +++ b/rust/pin-init/internal/src/init.rs
> @@ -251,6 +251,11 @@ fn init_fields(
> });
> // Again span for better diagnostics
> let write = quote_spanned!(ident.span()=> ::core::ptr::write);
> + // NOTE: the field accessor ensures that the initialized struct is not
> + // `repr(packed)`. If it were, the compiler would emit E0793. We do not support
> + // packed structs, since `Init::__init` requires an aligned pointer; the same
> + // requirement that the call to `ptr::write` below has.
> + // For more info see <https://github.com/Rust-for-Linux/pin-init/issues/112>
The emphasis should be unaligned fields instead of `repr(packed)`. Of course,
unaligned fields can only occur with `repr(packed)`, but packed structs can
contain well-aligned fields, too (e.g. 1-byte aligned members, or
`repr(packed(2))` with 2-byte aligned members, etc...). Rust permits creation of
references to these fields.
Something like:
NOTE: the field accessor ensures that the initialized field is properly
aligned. Unaligned fields will cause the compiler to emit E0793. We do not
support unaligned fields since `Init::__init` requires an aligned pointer;
the `ptr::write` below has the same requirement.
Also, it is not immediately clear to me which one, buyt one of the two occurance
should be `PinInit::__pin_init`?
Best,
Gary
> let accessor = if pinned {
> let project_ident = format_ident!("__project_{ident}");
> quote! {
> @@ -278,6 +283,11 @@ fn init_fields(
> InitializerKind::Init { ident, value, .. } => {
> // Again span for better diagnostics
> let init = format_ident!("init", span = value.span());
> + // NOTE: the field accessor ensures that the initialized struct is not
> + // `repr(packed)`. If it were, the compiler would emit E0793. We do not support
> + // packed structs, since `Init::__init` requires an aligned pointer; the same
> + // requirement that the call to `ptr::write` below has.
> + // For more info see <https://github.com/Rust-for-Linux/pin-init/issues/112>
> let (value_init, accessor) = if pinned {
> let project_ident = format_ident!("__project_{ident}");
> (
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors
2026-02-28 11:37 ` [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors Benno Lossin
2026-02-28 11:55 ` Gary Guo
@ 2026-02-28 14:11 ` Miguel Ojeda
2026-02-28 14:49 ` Benno Lossin
1 sibling, 1 reply; 5+ messages in thread
From: Miguel Ojeda @ 2026-02-28 14:11 UTC (permalink / raw)
To: Benno Lossin
Cc: Gary Guo, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Wedson Almeida Filho, stable, rust-for-linux, linux-kernel
On Sat, Feb 28, 2026 at 12:37 PM Benno Lossin <lossin@kernel.org> wrote:
>
> The affected stable trees that are still
> maintained are: 6.17, 6.16, 6.12, and 6.6.
Same here, i.e. 6.17 and 6.16 are not maintained anymore, so these can
be skipped.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors
2026-02-28 14:11 ` Miguel Ojeda
@ 2026-02-28 14:49 ` Benno Lossin
0 siblings, 0 replies; 5+ messages in thread
From: Benno Lossin @ 2026-02-28 14:49 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Gary Guo, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Wedson Almeida Filho, stable, rust-for-linux, linux-kernel
On Sat Feb 28, 2026 at 3:11 PM CET, Miguel Ojeda wrote:
> On Sat, Feb 28, 2026 at 12:37 PM Benno Lossin <lossin@kernel.org> wrote:
>>
>> The affected stable trees that are still
>> maintained are: 6.17, 6.16, 6.12, and 6.6.
>
> Same here, i.e. 6.17 and 6.16 are not maintained anymore, so these can
> be skipped.
Oh perfect, that means less work then. I wonder where I saw these, since
I checked the website, but now I of course don't see them there...
Cheers,
Benno
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors
2026-02-28 11:55 ` Gary Guo
@ 2026-02-28 14:56 ` Benno Lossin
0 siblings, 0 replies; 5+ messages in thread
From: Benno Lossin @ 2026-02-28 14:56 UTC (permalink / raw)
To: Gary Guo, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Wedson Almeida Filho
Cc: stable, rust-for-linux, linux-kernel
On Sat Feb 28, 2026 at 12:55 PM CET, Gary Guo wrote:
> On Sat Feb 28, 2026 at 11:37 AM GMT, Benno Lossin wrote:
>> diff --git a/rust/pin-init/internal/src/init.rs b/rust/pin-init/internal/src/init.rs
>> index da53adc44ecf..533029d53d30 100644
>> --- a/rust/pin-init/internal/src/init.rs
>> +++ b/rust/pin-init/internal/src/init.rs
>> @@ -251,6 +251,11 @@ fn init_fields(
>> });
>> // Again span for better diagnostics
>> let write = quote_spanned!(ident.span()=> ::core::ptr::write);
>> + // NOTE: the field accessor ensures that the initialized struct is not
>> + // `repr(packed)`. If it were, the compiler would emit E0793. We do not support
>> + // packed structs, since `Init::__init` requires an aligned pointer; the same
>> + // requirement that the call to `ptr::write` below has.
>> + // For more info see <https://github.com/Rust-for-Linux/pin-init/issues/112>
>
> The emphasis should be unaligned fields instead of `repr(packed)`. Of course,
> unaligned fields can only occur with `repr(packed)`, but packed structs can
> contain well-aligned fields, too (e.g. 1-byte aligned members, or
> `repr(packed(2))` with 2-byte aligned members, etc...). Rust permits creation of
> references to these fields.
Yeah that's a more accurate account of things.
> Something like:
>
> NOTE: the field accessor ensures that the initialized field is properly
> aligned. Unaligned fields will cause the compiler to emit E0793. We do not
> support unaligned fields since `Init::__init` requires an aligned pointer;
> the `ptr::write` below has the same requirement.
That's a much better suggestion, I'll send an updated series later
today.
> Also, it is not immediately clear to me which one, buyt one of the two occurance
> should be `PinInit::__pin_init`?
No, `PinInit::__pin_init` is never called from the macro, since that
only makes sense for structurally pinned fields. That info isn't
available at the callsite of `init!`. We emit it in `#[pin_data]` which
exposes it to `init!` via the `PinData`. That ZST has a method with the
same name as the field and it takes the respective initializer (so `impl
Init` or `impl PinInit`) and just runs said initializer.
This happens in the second hunk in the case where `pinned == true`.
Cheers,
Benno
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-02-28 14:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260228113713.1402110-1-lossin@kernel.org>
2026-02-28 11:37 ` [PATCH 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors Benno Lossin
2026-02-28 11:55 ` Gary Guo
2026-02-28 14:56 ` Benno Lossin
2026-02-28 14:11 ` Miguel Ojeda
2026-02-28 14:49 ` Benno Lossin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox