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

 rust/kernel/sync/lock.rs        | 35 +++++++++++++++++++++++++++++++----
 rust/kernel/sync/lock/global.rs |  5 ++++-
 2 files changed, 35 insertions(+), 5 deletions(-)
---
base-commit: dff64b072708ffef23c117fa1ee1ea59eb417807
change-id: 20250730-lock-t-when-t-is-pinned-292474504acb

Best regards,
-- 
Daniel Almeida <daniel.almeida@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>