From: Alice Ryhl <aliceryhl@google.com>
To: Benno Lossin <lossin@kernel.org>
Cc: "Gary Guo" <gary@garyguo.net>, "Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Fiona Behrens" <me@kloenk.dev>,
"Tim Chirananthavat" <theemathas@gmail.com>,
stable@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: pin-init: replace shadowed return token by `unsafe`-to-create token
Date: Wed, 11 Mar 2026 16:02:46 +0000 [thread overview]
Message-ID: <abGSJlUHmPEC1kJT@google.com> (raw)
In-Reply-To: <20260311105056.1425041-1-lossin@kernel.org>
On Wed, Mar 11, 2026 at 11:50:49AM +0100, Benno Lossin wrote:
> The reason we initially used the shadowing solution was because an
> alternative solution used a builder pattern. Gary writes [3]:
>
> In the early builder-pattern based InitOk, having a single InitOk
> type for token is unsound because one can launder an InitOk token
> used for one place to another initializer. I used a branded lifetime
> solution, and then you figured out that using a shadowed type would
> work better because nobody could construct it at all.
>
> The laundering issue does not apply to the approach we ended up with
> today.
You could always make the unsafe-to-construct token generic over a
locally-defined type to avoid issues with laundering.
> Reported-by: Tim Chirananthavat <theemathas@gmail.com>
> Link: https://github.com/rust-lang/rust/issues/153535 [1]
> Link: https://github.com/rust-lang/rfcs/pull/3444#issuecomment-4016145373 [2]
> Link: https://github.com/rust-lang/rust/issues/153535#issuecomment-4017620804 [3]
> Fixes: fc6c6baa1f40 ("rust: init: add initialization macros")
> Cc: stable@vger.kernel.org
> Signed-off-by: Benno Lossin <lossin@kernel.org>
> ---
> This is not yet a soundness issue, but could become one in the future
> when TAIT gets stabilized in a form that allows the problem described.
Let's just land it now regardless.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Alice
next prev parent reply other threads:[~2026-03-11 16:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 10:50 [PATCH] rust: pin-init: replace shadowed return token by `unsafe`-to-create token Benno Lossin
2026-03-11 12:51 ` Gary Guo
2026-03-11 13:01 ` Danilo Krummrich
2026-03-11 16:04 ` Alice Ryhl
2026-03-11 16:11 ` Gary Guo
2026-03-11 18:14 ` Benno Lossin
2026-03-11 16:02 ` Alice Ryhl [this message]
2026-03-12 7:57 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abGSJlUHmPEC1kJT@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=me@kloenk.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=theemathas@gmail.com \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.