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: <953481fa-785b-4329-9306-51db6620f611@kernel.org>
Date: Wed, 10 Sep 2025 17:08:05 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Benno Lossin <lossin@...nel.org>
Cc: Boqun Feng <boqun.feng@...il.com>, Alice Ryhl <aliceryhl@...gle.com>,
 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 9/10/25 4:59 PM, 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.

And as Alice said, getting some experience from real applications is not the
worst thing. We can always change it if we see it causing too much pain.