linux-kernel - Re: [PATCH v2] rust: pin-init: add `#[bind]` attribute to access previously initialized fields

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: <aMGT6h5yIcpR3mCg@tardis-2.local>
Date: Wed, 10 Sep 2025 08:06:18 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Benno Lossin <lossin@...nel.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Danilo Krummrich <dakr@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>, Fiona Behrens <me@...enk.dev>,
	Alban Kurti <kurti@...icto.ai>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rust: pin-init: add `#[bind]` attribute to access
 previously initialized fields

On Wed, Sep 10, 2025 at 04:59:11PM +0200, Benno Lossin wrote:
> On Wed Sep 10, 2025 at 4:02 PM CEST, Boqun Feng wrote:
> > On Wed, Sep 10, 2025 at 02:19:00PM +0200, Benno Lossin wrote:
> >> On Wed Sep 10, 2025 at 12:40 PM CEST, Alice Ryhl wrote:
> >> > On Wed, Sep 10, 2025 at 12:36 PM Benno Lossin <lossin@...nel.org> wrote:
> >> >>
> >> >> On Wed Sep 10, 2025 at 12:17 PM CEST, Alice Ryhl wrote:
> >> >> > On Wed, Sep 10, 2025 at 12:07:53PM +0200, Benno Lossin wrote:
> >> >> >> Assigning a field a value in an initializer macro can be marked with the
> >> >> >> `#[bind]` attribute. Doing so creates a `let` binding with the same
> >> >> >> name. This `let` binding has the type `Pin<&mut T>` if the field is
> >> >> >> structurally pinned or `&mut T` otherwise (where `T` is the type of the
> >> >> >> field).
> >> >> >>
> >> >> >> Signed-off-by: Benno Lossin <lossin@...nel.org>
> >> >> >
> >> >> > Is there a reason we can't apply this to all fields and avoid the
> >> >> > attribute?
> >> >>
> >> >> Adding the attribute was due to Boqun's concern on v1 [1]. I think it
> >> >> might be surprising too, but I'm also happy with no attribute.
> >> >>
> >> >> [1]: https://lore.kernel.org/all/aLshd0_C-1rh3FAg@tardis-2.local
> >> >
> >> > IMO the ideal is if it works without an attribute. Perhaps trying that
> >> > in the kernel is a reasonable experiment to find out whether that's
> >> > reasonable to do for the general language feature?
> >> 
> >> @Boqun what is your opinion on this?
> >> 
> >
> > If we plan to make the in-place initializer language feature behave
> > similar, as I asked here [1], then dropping `#[bind]` seems good to me.
> 
> I don't think we can promise how that language feature is going to look
> like. It will definitely support accessing already initialized fields,
> but in what form remains to be seen.
> 

Sure, but in kernel we are able to stay the same as whatever the
language feature will be like, right?

In other words, as long as we propose the same thing to the language
feature and keep kernel code and language feature synced (presumbly
there could be some more discussion on the syntax when presented to Rust
commmunity), then I'm think it's fine.

Thanks!

Regards,
Boqun

> ---
> Cheers,
> Benno
> 
> > [1]: https://lore.kernel.org/rust-for-linux/aLshd0_C-1rh3FAg@tardis-2.local/
> >
> > Thanks!
> >
> > Regards,
> > Boqun
> >
> >> I'm open to take v2 or v1, whatever you guys prefer.
> >> 
> >> ---
> >> Cheers,
> >> Benno
>