[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ-ks9mJJ+Rsmwa3zYq=1kLCox0tKvbKu6FBOJH4S3ed0hdjwA@mail.gmail.com>
Date: Thu, 8 Jan 2026 06:07:14 -0500
From: Tamir Duberstein <tamird@...il.com>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, Daniel Gomez <da.gomez@...nel.org>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/10] rust: xarray: simplify `Guard::load`
On Thu, Jan 8, 2026 at 4:38 AM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>
> Tamir Duberstein <tamird@...il.com> writes:
>
> > On Wed, Jan 7, 2026 at 2:37 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
> >>
> >> Tamir Duberstein <tamird@...il.com> writes:
> >>
> >> > On Wed, Dec 3, 2025 at 5:27 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
> >> >>
> >> >> Simplify the implementation by removing the closure-based API from
> >> >> `Guard::load` in favor of returning `Option<NonNull<c_void>>` directly.
> >> >
> >> > This is not sound. The returned pointer can now outlive the guard and
> >> > mutation through that pointer is trivial.
> >>
> >> I don't think this is unsound. If we returned a reference instead, it
> >> would be, but we are returning a raw pointer. Dereferencing the pointer
> >> is unsafe and requires proper safety comments.
> >
> > You may be right, strictly speaking, but it is most definitely a
> > footgun. This is a special pointer that requires more careful handling
> > than other raw pointers.
>
> I would disagree. Dereferencing any raw pointer requires the same
> checks, and knowing this one is valid and satisfies lifetime
> requirements is no different than others.
>
> It is also a private method that is only used in this particular impl
> block.
>
> At any rate, I'm fine with dropping the change. The reason I did it was
> because I had to double take when I read the previous code. I think the
> original code is has some unnecessary complexity with the closure.
Simplification is always welcome. The current shape of this code was
guided by the desire to avoid the footgun we're discussing here.
>
> Best regards,
> Andreas Hindborg
>
>
>
Powered by blists - more mailing lists