linux-next: build failure after merge of the tip tree

linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

error[E0594]: cannot assign to data in dereference of `lock::Guard<'_, T, MutexBackend>`
  --> rust/kernel/debugfs/traits.rs:64:9
   |
64 |         *self.lock() = val;
   |         ^^^^^^^^^^^^ cannot assign
   |
   = help: trait `DerefMut` is required to modify through a dereference, but it is not implemented for `lock::Guard<'_, T, MutexBackend>`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0594`.

Caused by commit

  da123f0ee40f ("rust: lock: guard: Add T: Unpin bound to DerefMut")

I have used the tip tree from next-20251021 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the tip tree

[Boqun Feng]

On Wed, Oct 22, 2025 at 11:46:44AM +1100, Stephen Rothwell wrote:
> Hi all,
> 

Hi Stephen,

Thanks for reporting this.

Cc Mathhew and Danilo,

> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> error[E0594]: cannot assign to data in dereference of `lock::Guard<'_, T, MutexBackend>`
>   --> rust/kernel/debugfs/traits.rs:64:9
>    |
> 64 |         *self.lock() = val;
>    |         ^^^^^^^^^^^^ cannot assign
>    |
>    = help: trait `DerefMut` is required to modify through a dereference, but it is not implemented for `lock::Guard<'_, T, MutexBackend>`
> 

Could we make the `impl Reader` for `Mutex<T>` to bound where `T:
Unpin`? Since `Mutex<T>` is structurally pinning `T`, you cannot use
`*self.lock()` to overwrite `T` directly. And that'll fix this.

Thanks!

Regards,
Boqun

> error: aborting due to 1 previous error
> 
> For more information about this error, try `rustc --explain E0594`.
> 
> Caused by commit
> 
>   da123f0ee40f ("rust: lock: guard: Add T: Unpin bound to DerefMut")
> 
> I have used the tip tree from next-20251021 for today.
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: linux-next: build failure after merge of the tip tree

[Boqun Feng]

On Tue, Oct 21, 2025 at 10:18:58PM -0400, Boqun Feng wrote:
> On Wed, Oct 22, 2025 at 11:46:44AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> 
> Hi Stephen,
> 
> Thanks for reporting this.
> 
> Cc Mathhew and Danilo,
> 

(now really Cc them...)

Regards,
Boqun

> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > error[E0594]: cannot assign to data in dereference of `lock::Guard<'_, T, MutexBackend>`
> >   --> rust/kernel/debugfs/traits.rs:64:9
> >    |
> > 64 |         *self.lock() = val;
> >    |         ^^^^^^^^^^^^ cannot assign
> >    |
> >    = help: trait `DerefMut` is required to modify through a dereference, but it is not implemented for `lock::Guard<'_, T, MutexBackend>`
> > 
> 
> Could we make the `impl Reader` for `Mutex<T>` to bound where `T:
> Unpin`? Since `Mutex<T>` is structurally pinning `T`, you cannot use
> `*self.lock()` to overwrite `T` directly. And that'll fix this.
> 
> Thanks!
> 
> Regards,
> Boqun
> 
> > error: aborting due to 1 previous error
> > 
> > For more information about this error, try `rustc --explain E0594`.
> > 
> > Caused by commit
> > 
> >   da123f0ee40f ("rust: lock: guard: Add T: Unpin bound to DerefMut")
> > 
> > I have used the tip tree from next-20251021 for today.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> 
> 

[PATCH] rust: debugfs: Implement Reader for Mutex<T> only when T is Unpin

[Boqun Feng]

Since we are going to make `Mutex<T>` structurally pin the data (i.e.
`T`), therefore `.lock()` function only returns a `Guard` that can
dereference a mutable reference to `T` if only `T` is `Unpin`, therefore
restrict the impl `Reader` block of `Mutex<T>` to that.

Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
 rust/kernel/debugfs/traits.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/debugfs/traits.rs b/rust/kernel/debugfs/traits.rs
index ab009eb254b3..ba7ec5a900b8 100644
--- a/rust/kernel/debugfs/traits.rs
+++ b/rust/kernel/debugfs/traits.rs
@@ -50,7 +50,7 @@ pub trait Reader {
     fn read_from_slice(&self, reader: &mut UserSliceReader) -> Result;
 }
 
-impl<T: FromStr> Reader for Mutex<T> {
+impl<T: FromStr + Unpin> Reader for Mutex<T> {
     fn read_from_slice(&self, reader: &mut UserSliceReader) -> Result {
         let mut buf = [0u8; 128];
         if reader.len() > buf.len() {
-- 
2.51.0

Re: [PATCH] rust: debugfs: Implement Reader for Mutex<T> only when T is Unpin

[Danilo Krummrich]

On 10/22/25 5:42 AM, Boqun Feng wrote:
> Since we are going to make `Mutex<T>` structurally pin the data (i.e.
> `T`), therefore `.lock()` function only returns a `Guard` that can
> dereference a mutable reference to `T` if only `T` is `Unpin`, therefore
> restrict the impl `Reader` block of `Mutex<T>` to that.
> 
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>

I assume this can go through the driver-core tree, since it's only about a
conflict in linux-next?

Re: [PATCH] rust: debugfs: Implement Reader for Mutex<T> only when T is Unpin

[Danilo Krummrich]

On 10/22/25 11:07 AM, Danilo Krummrich wrote:
> On 10/22/25 5:42 AM, Boqun Feng wrote:
>> Since we are going to make `Mutex<T>` structurally pin the data (i.e.
>> `T`), therefore `.lock()` function only returns a `Guard` that can
>> dereference a mutable reference to `T` if only `T` is `Unpin`, therefore
>> restrict the impl `Reader` block of `Mutex<T>` to that.
>>
>> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> 
> I assume this can go through the driver-core tree, since it's only about a
> conflict in linux-next?

Sorry, I confused this, obviously your tree is broken without this change,
please feel free to take it.

Acked-by: Danilo Krummrich <dakr@kernel.org>