All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Waiman Long" <longman@redhat.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 0/3] Groundwork for Lock<T> when T is pinned
Date: Fri, 1 Aug 2025 09:01:51 +0000	[thread overview]
Message-ID: <aIyCf85_Xe6etC8Q@google.com> (raw)
In-Reply-To: <20250730-lock-t-when-t-is-pinned-v1-0-1b97d5f28aa2@collabora.com>

On Wed, Jul 30, 2025 at 02:14:43PM -0300, Daniel Almeida wrote:
> It's currently impossible to have a pinned struct within the Lock<T> type.
> This is problematic, because drivers might want to do this for various
> reasons, specially as they grow in complexity.
> 
> A trivial example is:
> 
> struct Foo {
>   #[pin]
>   bar: Mutex<Bar>,
>   #[pin]
>   p: PhantomPinned,
> }
> 
> struct Bar {
>   #[pin]
>   baz: Mutex<Baz>,
>   #[pin]
>   p: PhantomPinned,
> }
> 
> Note that Bar is pinned, so having it in a Mutex makes it impossible to
> instantiate a Foo that pins the Bar in bar. This is specially undesirable,
> since Foo is already pinned, and thus, it could trivially enforce that its
> bar field is pinned as well.
> 
> This can be trivially solved by using Pin<KBox<Bar>> instead of
> structurally pinning, at the cost of an extra (completely unneeded)
> allocation and ugly syntax.
> 
> This series lays out the groundwork to make the above possible without any
> extra allocations.
> 
> - Patch 1 structurally pins the 'data' field in Lock<T>
> - Patch 2 constrains the DerefMut implementation for safety reasons
> - Patch 3 adds an accessor to retrieve a Pin<&mut T>
> 
> Note that this is just the beginning of the work needed to make a Pin<&mut
> T> actually useful due to pin projections being currently unsupported.
> 
> In other words, it is currently impossible (even with the current patch) to
> do this:
> 
> let mut data: MutexGuard<'_, Data> = mutex.lock();
> let mut data: Pin<&mut Data> = data.as_mut();
> let foo = &mut data.foo; // <- won't compile
> 
> The above is something that Benno is working on.
> 
> Thanks Boqun, Benno and the rest of the team for brainstorming the issue
> and for and laying out a series of steps to implement a solution.
> 
> ---
> Daniel Almeida (3):
>       rust: lock: pin the inner data
>       rust: lock: guard: add T: Unpin bound to DerefMut
>       rust: lock: add a Pin<&mut T> accessor

With the things that Benno said fixed:

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

      parent reply	other threads:[~2025-08-01  9:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-30 17:14 [PATCH 0/3] Groundwork for Lock<T> when T is pinned Daniel Almeida
2025-07-30 17:14 ` [PATCH 1/3] rust: lock: pin the inner data Daniel Almeida
2025-07-31 18:49   ` Benno Lossin
2025-07-30 17:14 ` [PATCH 2/3] rust: lock: guard: add T: Unpin bound to DerefMut Daniel Almeida
2025-07-30 19:32   ` Benno Lossin
2025-07-30 17:14 ` [PATCH 3/3] rust: lock: add a Pin<&mut T> accessor Daniel Almeida
2025-07-31 18:52   ` Benno Lossin
2025-08-01  9:01 ` Alice Ryhl [this message]

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=aIyCf85_Xe6etC8Q@google.com \
    --to=aliceryhl@google.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=lossin@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=will@kernel.org \
    /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.