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: <DFL248YSG9CS.GQNSONYLIDWQ@kernel.org>
Date: Sat, 10 Jan 2026 17:41:00 +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>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Alban Kurti"
 <kurti@...icto.ai>
Cc: <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH 06/12] rust: pin-init: rewrite `#[pin_data]` using `syn`

On Fri Jan 9, 2026 at 5:46 PM CET, Gary Guo wrote:
> On Fri Jan 9, 2026 at 4:39 PM GMT, Benno Lossin wrote:
>> On Fri Jan 9, 2026 at 1:47 PM CET, Gary Guo wrote:
>>> On Thu Jan 8, 2026 at 1:50 PM GMT, Benno Lossin wrote:
>>>> +fn strip_pin_annotations(struct_: &mut syn::ItemStruct) {
>>>> +    for field in &mut struct_.fields {
>>>> +        field.attrs.retain(|a| !a.path().is_ident("pin"));
>>>> +    }
>>>> +}
>>>
>>> Multiple places have similar things for stripping annotations and checking if
>>> structurally pinned. Would it make sense to do this at the very beginning, and
>>> build a `HashSet` of structurally pinned fields, and use that as canonical
>>> source for all generate_ functions?
>>
>> There is https://github.com/Rust-for-Linux/pin-init/pull/94, and I don't
>> want to take away their work. I'll contact them and see if we can fold
>> it into this commit/series.
>
> I don't think that's the same? I am proposing remove `#[pin]` and build a set at
> the very beginning of `fn pin_data` and just use that set. Which is not what the
> reference PR does.

Oh yeah you're right. But `Field` doesn't implement `Hash`, so we sadly
can't create a set of pinned fields. I'll just create a Vec with a bool
and pass that around.

Cheers,
Benno

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ