mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Gary Guo" <gary@garyguo.net>
To: "Tamir Duberstein" <tamird@gmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Gomez" <da.gomez@kernel.org>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/10] rust: xarray: simplify `Guard::load`
Date: Fri, 09 Jan 2026 16:57:57 +0000	[thread overview]
Message-ID: <DFK7UOBJOVVJ.16QPQCTSGFJHI@garyguo.net> (raw)
In-Reply-To: <CAJ-ks9mJJ+Rsmwa3zYq=1kLCox0tKvbKu6FBOJH4S3ed0hdjwA@mail.gmail.com>

On Thu Jan 8, 2026 at 11:07 AM GMT, Tamir Duberstein wrote:
> On Thu, Jan 8, 2026 at 4:38 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> Tamir Duberstein <tamird@gmail.com> writes:
>>
>> > On Wed, Jan 7, 2026 at 2:37 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>> >>
>> >> Tamir Duberstein <tamird@gmail.com> writes:
>> >>
>> >> > On Wed, Dec 3, 2025 at 5:27 PM Andreas Hindborg <a.hindborg@kernel.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.

Using a closure isn't any better than just returning a raw pointer. If you want
a pointer you can just have a identity closure and there's nothing preventing
you from doing that.

Even with `T::borrow` inside the closure this isn't providing any security as
the code would still compile if you change `'_` in the return signature into
`'static`.

The only defence here is really the `unsafe` and safety comment.

I would prefer to not have closure in this case.

Best,
Gary


  reply	other threads:[~2026-01-09 16:58 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-03 22:26 [PATCH 00/10] rust: xarray: add entry API with preloading Andreas Hindborg
2025-12-03 22:26 ` [PATCH 01/10] rust: xarray: minor formatting fixes Andreas Hindborg
2025-12-29 15:56   ` Tamir Duberstein
2025-12-29 15:58     ` Tamir Duberstein
2026-01-21 15:45   ` Gary Guo
2025-12-03 22:26 ` [PATCH 02/10] rust: xarray: add debug format for `StoreError` Andreas Hindborg
2025-12-29 15:58   ` Tamir Duberstein
2026-01-21 15:46   ` Gary Guo
2025-12-03 22:26 ` [PATCH 03/10] rust: xarray: add `contains_index` method Andreas Hindborg
2025-12-29 15:59   ` Tamir Duberstein
2026-01-07 18:34     ` Andreas Hindborg
2026-01-07 18:38       ` Tamir Duberstein
2026-01-08  9:29         ` Andreas Hindborg
2026-01-08 11:05           ` Tamir Duberstein
2026-01-09 10:38             ` Andreas Hindborg
2026-01-09 15:59               ` Tamir Duberstein
2026-01-09 17:04                 ` Gary Guo
2025-12-03 22:26 ` [PATCH 04/10] rust: xarray: add `XArrayState` Andreas Hindborg
2025-12-29 16:04   ` Tamir Duberstein
2026-01-07 18:48     ` Andreas Hindborg
2026-01-08 14:22       ` Gary Guo
2025-12-03 22:26 ` [PATCH 05/10] rust: xarray: use `xas_load` instead of `xa_load` in `Guard::load` Andreas Hindborg
2025-12-29 16:06   ` Tamir Duberstein
2026-01-07 19:19     ` Andreas Hindborg
2026-01-07 20:06       ` Tamir Duberstein
2026-01-08  9:30         ` Andreas Hindborg
2025-12-03 22:26 ` [PATCH 06/10] rust: xarray: simplify `Guard::load` Andreas Hindborg
2025-12-29 16:07   ` Tamir Duberstein
2026-01-07 19:25     ` Andreas Hindborg
2026-01-07 20:08       ` Tamir Duberstein
2026-01-08  9:38         ` Andreas Hindborg
2026-01-08 11:07           ` Tamir Duberstein
2026-01-09 16:57             ` Gary Guo [this message]
2025-12-03 22:26 ` [PATCH 07/10] rust: xarray: add `find_next` and `find_next_mut` Andreas Hindborg
2025-12-29 16:11   ` Tamir Duberstein
2026-01-07 19:29     ` Andreas Hindborg
2025-12-03 22:26 ` [PATCH 08/10] rust: xarray: add entry API Andreas Hindborg
2025-12-29 16:25   ` Tamir Duberstein
2026-01-08  9:25     ` Andreas Hindborg
2026-01-08 11:03       ` Tamir Duberstein
2026-01-09 10:36         ` Andreas Hindborg
2026-01-09 16:00           ` Tamir Duberstein
2025-12-03 22:26 ` [PATCH 09/10] rust: xarray: add preload API Andreas Hindborg
2026-01-21 15:56   ` Gary Guo
2026-01-21 19:09     ` Andreas Hindborg
2025-12-03 22:26 ` [PATCH 10/10] rust: xarray: fix false positive lockdep warnings Andreas Hindborg
2025-12-29 16:29   ` Tamir Duberstein
2026-02-06 14:22     ` Andreas Hindborg
2026-01-21 15:59   ` Gary Guo
2026-01-21 19:01     ` Andreas Hindborg
2026-01-21 19:10       ` Gary Guo
2026-01-21 20:17         ` Andreas Hindborg
2026-01-22  9:20   ` Alice Ryhl
2026-02-06 14:21     ` Andreas Hindborg

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=DFK7UOBJOVVJ.16QPQCTSGFJHI@garyguo.net \
    --to=gary@garyguo.net \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=da.gomez@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=tamird@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®