linux-kernel - Re: [PATCH 08/12] rust: pin-init: rewrite the initializer macros using `syn`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DFK8F3L2BMS2.3G1BAQSU145IH@kernel.org>
Date: Fri, 09 Jan 2026 18:24:37 +0100
From: "Benno Lossin" <lossin@...nel.org>
To: "Gary Guo" <gary@...yguo.net>, "Miguel Ojeda" <ojeda@...nel.org>, "Boqun
 Feng" <boqun.feng@...il.com>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Andreas Hindborg" <a.hindborg@...nel.org>,
 "Alice Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
 "Danilo Krummrich" <dakr@...nel.org>, "Fiona Behrens" <me@...enk.dev>,
 "Christian Schrefl" <chrisi.schrefl@...il.com>, "Alban Kurti"
 <kurti@...icto.ai>
Cc: <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH 08/12] rust: pin-init: rewrite the initializer macros
 using `syn`

On Fri Jan 9, 2026 at 2:45 PM CET, Gary Guo wrote:
> On Thu Jan 8, 2026 at 1:50 PM GMT, Benno Lossin wrote:
>> +    let init_kind = get_init_kind(rest, &mut errors);
>> +    let zeroable_check = match init_kind {
>> +        InitKind::Normal => quote!(),
>> +        InitKind::Zeroing => quote! {
>> +            // The user specified `..Zeroable::zeroed()` at the end of the list of fields.
>> +            // Therefore we check if the struct implements `Zeroable` and then zero the memory.
>> +            // This allows us to also remove the check that all fields are present (since we
>> +            // already set the memory to zero and that is a valid bit pattern).
>> +            fn assert_zeroable<T: ?::core::marker::Sized>(_: *mut T)
>> +            where T: ::pin_init::Zeroable
>> +            {}
>> +            // Ensure that the struct is indeed `Zeroable`.
>> +            assert_zeroable(#slot);
>> +            // SAFETY: The type implements `Zeroable` by the check above.
>> +            unsafe { ::core::ptr::write_bytes(#slot, 0, 1) };
>
> Can this be `#slot.write(::pin_init::zeroed())`?

That could overflow the stack?

>> +        },
>> +    };

>> +        InitKind::Zeroing => quote! {
>> +            // We use unreachable code to ensure that all fields have been mentioned at most once.
>> +            // Since the user specified `..Zeroable::zeroed()` at the end, all missing fields will
>> +            // be zeroed. This struct initializer will still be type-checked and complain with a
>> +            // very natural error message if a field is mentioned more than once, or doesn't exist.
>> +            #[allow(unreachable_code, clippy::diverging_sub_expression, unused_assignments)]
>> +            // SAFETY: this code is never executed.
>> +            let _ = || unsafe {
>> +                let mut zeroed = ::core::mem::zeroed();
>> +                ::core::ptr::write(slot, zeroed);
>
> Looks like the comment explaining why this is done gets missed.

Good catch!

>> +                zeroed = ::core::mem::zeroed();
>> +                ::core::ptr::write(slot, #path {
>> +                    #(
>> +                        #fields: ::core::panic!(),
>> +                    )*
>> +                    ..zeroed
>
> Would just ::core::mem::zeroed() here work or does it have same inference issue?
> IIUC the type inference should work here as ..Default::default() works.

I haven't checked this, will do so.

Cheers,
Benno