All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gary Guo" <gary@garyguo.net>
To: "Benno Lossin" <lossin@kernel.org>, "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>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>
Cc: <stable@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors
Date: Mon, 02 Mar 2026 14:14:19 +0000	[thread overview]
Message-ID: <DGSCXPXGW2SW.D8VR5QI5OVNT@garyguo.net> (raw)
In-Reply-To: <20260302140424.4097655-2-lossin@kernel.org>

On Mon Mar 2, 2026 at 2:04 PM GMT, Benno Lossin wrote:
> The functions `[Pin]Init::__[pinned_]init` and `ptr::write` called from
> the `init!` macro require the passed pointer to be aligned. This fact is
> ensured by the creation of field accessors to previously initialized
> fields.
> 
> Since we missed this very important fact from the beginning [1],
> document it in the code.
> 
> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1]
> Fixes: 90e53c5e70a6 ("rust: add pin-init API core")
> Cc: stable@vger.kernel.org # 6.19.y and 6.18.y: patch should apply without issues
> Cc: stable@vger.kernel.org # 6.12.y and 6.6.y: need prerequisite see below `---` for more info

Hmm, if this patch is applied as is, the --- below is going to be cut out and
this line wouldn't make sense.

Perhaps we should just put

    Cc: stable@vger.kernel.org # 6.12.y and 6.6.y: need commit 42415d163e5d ("rust: pin-init: add references to previously initialized fields")

Or leave this cc out and ask for manual picking?

> Signed-off-by: Benno Lossin <lossin@kernel.org>

Reviewed-by: Gary Guo <gary@garyguo.net>

Best,
Gary

> ---
> As already explained in the previous email, we discovered an unsoundness
> in pin-init that exists since the beginning, but was unknowingly fixed
> in commit 42415d163e5d ("rust: pin-init: add references to previously
> initialized fields").
> 
> We introduced pin-init in 90e53c5e70a6 ("rust: add pin-init API core"),
> which was included in 6.4. The affected stable trees that are still
> maintained are: 6.12 and 6.6. Note that 6.18 and 6.19 already contain
> 42415d163e5d, so they are unaffected.
> 
> We still should backport this piece of documentation explaining the need
> for the field accessors for soundness. For this reasons we also want to
> backport it to 6.18 and 6.19.
> 
> Note that this patch depends on 42415d163e5d; so the only versions this
> patch can go in directly are 6.18 and 6.19. I will send separate patch
> series' for the older versions. The series' will include a backport of
> 42415d163e5d as well as a modified version of this patch, since this
> patch depends on the `syn` rewrite, which is not present in older
> versions.
> ---
>  rust/pin-init/internal/src/init.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)


  reply	other threads:[~2026-03-02 14:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-02 14:04 [PATCH v2 1/2] rust: pin-init: internal: init: remove `#[disable_initialized_field_access]` Benno Lossin
2026-03-02 14:04 ` [PATCH v2 2/2] rust: pin-init: internal: init: document load-bearing fact of field accessors Benno Lossin
2026-03-02 14:14   ` Gary Guo [this message]
2026-03-02 14:20     ` Miguel Ojeda
2026-03-02 14:48       ` Benno Lossin
2026-03-02 14:09 ` [PATCH v2 1/2] rust: pin-init: internal: init: remove `#[disable_initialized_field_access]` Gary Guo
2026-03-02 20:06 ` Janne Grunau
2026-03-03 11:31 ` Alice Ryhl
2026-03-04  6:59   ` Benno Lossin
2026-03-04  7:06     ` Alice Ryhl
2026-03-04 12:26     ` Miguel Ojeda
2026-03-05  8:05       ` Benno Lossin
2026-03-06 10:07 ` 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=DGSCXPXGW2SW.D8VR5QI5OVNT@garyguo.net \
    --to=gary@garyguo.net \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=wedsonaf@gmail.com \
    /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.