[PATCH 0/5] Rust beta (1.87) and nightly (1.88) lint cleanups

[PATCH 0/5] Rust beta (1.87) and nightly (1.88) lint cleanups

[Miguel Ojeda]

Now that Rust 1.87.0 is close to release, clean up the new lints that appeared.

It may be that one of the patches is not needed by the time it releases, but
I prefer to not wait much longer since I would like to land this for -rc6 so
that it is clean for release.

In addition, clean some nightly (1.88.0) ones too.

Miguel Ojeda (5):
  objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0
  rust: clean Rust 1.87.0's `clippy::ptr_eq` lints
  rust: clean Rust 1.88.0's `unnecessary_transmutes` lint
  rust: clean Rust 1.88.0's warning about `clippy::disallowed_macros`
    configuration
  rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

 .clippy.toml                              |  2 +-
 drivers/gpu/nova-core/gpu.rs              |  2 +-
 init/Kconfig                              |  3 ++
 rust/bindings/lib.rs                      |  1 +
 rust/kernel/alloc/kvec.rs                 |  2 +-
 rust/kernel/list.rs                       | 12 +++---
 rust/kernel/str.rs                        | 46 +++++++++++------------
 rust/macros/kunit.rs                      | 13 ++-----
 rust/macros/module.rs                     | 19 +++-------
 rust/macros/paste.rs                      |  2 +-
 rust/pin-init/internal/src/pinned_drop.rs |  3 +-
 rust/uapi/lib.rs                          |  1 +
 tools/objtool/check.c                     |  1 +
 13 files changed, 49 insertions(+), 58 deletions(-)


base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e
--
2.49.0

[PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Miguel Ojeda]

Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report:

    rust/core.o: warning: objtool: _R..._4core9panicking9panic_fmt() falls
    through to next function _R..._4core9panicking18panic_nounwind_fmt()

    rust/core.o: warning: objtool: _R..._4core9panicking18panic_nounwind_fmt()
    falls through to next function _R..._4core9panicking5panic()

The reason is that `rust_begin_unwind` is now mangled:

    _R..._7___rustc17rust_begin_unwind

Thus add the mangled one to the list so that `objtool` knows it is
actually `noreturn`.

See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions")
for more details.

Alternatively, we could remove the fixed one in `noreturn.h` and relax
this test to cover both, but it seems best to be strict as long as we can.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 tools/objtool/check.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 3a411064fa34..b21b12ec88d9 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -227,6 +227,7 @@ static bool is_rust_noreturn(const struct symbol *func)
 	       str_ends_with(func->name, "_4core9panicking19assert_failed_inner")			||
 	       str_ends_with(func->name, "_4core9panicking30panic_null_pointer_dereference")		||
 	       str_ends_with(func->name, "_4core9panicking36panic_misaligned_pointer_dereference")	||
+	       str_ends_with(func->name, "_7___rustc17rust_begin_unwind")				||
 	       strstr(func->name, "_4core9panicking13assert_failed")					||
 	       strstr(func->name, "_4core9panicking11panic_const24panic_const_")			||
 	       (strstr(func->name, "_4core5slice5index24slice_") &&
--
2.49.0

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Joel Fernandes]

Hello Miguel,

On Fri, May 02, 2025 at 04:02:33PM +0200, Miguel Ojeda wrote:
> Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report:
> 
>     rust/core.o: warning: objtool: _R..._4core9panicking9panic_fmt() falls
>     through to next function _R..._4core9panicking18panic_nounwind_fmt()
> 
>     rust/core.o: warning: objtool: _R..._4core9panicking18panic_nounwind_fmt()
>     falls through to next function _R..._4core9panicking5panic()

We are seeing a similar issue with the patch [1]:

  RUSTC [M] drivers/gpu/nova-core/nova_core.o
drivers/gpu/nova-core/nova_core.o: warning: objtool:
<nova_core::vbios::PciAtBiosImage as
core::convert::TryFrom<nova_core::vbios::BiosImageBase>>::try_from() falls
through to next function <nova_core::vbios::FwSecBiosImage>::fwsec_header()

The code in concern is implementing try_from():
+
+impl TryFrom<BiosImageBase> for PciAtBiosImage {
+    type Error = Error;
+
+    fn try_from(base: BiosImageBase) -> Result<Self> {

I dumped the codegen [2] for this function and at the end of the codegen, there
is a call instruction to to the fwsec_header() function.

Any thoughts on how to fix the warning?

thanks,

 - Joel

[1] https://lore.kernel.org/all/20250420-nova-frts-v1-13-ecd1cca23963@nvidia.com/
[2] https://paste.debian.net/1374516/


> The reason is that `rust_begin_unwind` is now mangled:
> 
>     _R..._7___rustc17rust_begin_unwind
> 
> Thus add the mangled one to the list so that `objtool` knows it is
> actually `noreturn`.
> 
> See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions")
> for more details.
> 
> Alternatively, we could remove the fixed one in `noreturn.h` and relax
> this test to cover both, but it seems best to be strict as long as we can.
> 
> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  tools/objtool/check.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 3a411064fa34..b21b12ec88d9 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -227,6 +227,7 @@ static bool is_rust_noreturn(const struct symbol *func)
>  	       str_ends_with(func->name, "_4core9panicking19assert_failed_inner")			||
>  	       str_ends_with(func->name, "_4core9panicking30panic_null_pointer_dereference")		||
>  	       str_ends_with(func->name, "_4core9panicking36panic_misaligned_pointer_dereference")	||
> +	       str_ends_with(func->name, "_7___rustc17rust_begin_unwind")				||
>  	       strstr(func->name, "_4core9panicking13assert_failed")					||
>  	       strstr(func->name, "_4core9panicking11panic_const24panic_const_")			||
>  	       (strstr(func->name, "_4core5slice5index24slice_") &&
> --
> 2.49.0

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Joel Fernandes]

On Tue, May 13, 2025 at 02:07:57PM -0400, Joel Fernandes wrote:
> Hello Miguel,
> 
> On Fri, May 02, 2025 at 04:02:33PM +0200, Miguel Ojeda wrote:
> > Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report:
> > 
> >     rust/core.o: warning: objtool: _R..._4core9panicking9panic_fmt() falls
> >     through to next function _R..._4core9panicking18panic_nounwind_fmt()
> > 
> >     rust/core.o: warning: objtool: _R..._4core9panicking18panic_nounwind_fmt()
> >     falls through to next function _R..._4core9panicking5panic()
> 
> We are seeing a similar issue with the patch [1]:
> 
>   RUSTC [M] drivers/gpu/nova-core/nova_core.o
> drivers/gpu/nova-core/nova_core.o: warning: objtool:
> <nova_core::vbios::PciAtBiosImage as
> core::convert::TryFrom<nova_core::vbios::BiosImageBase>>::try_from() falls
> through to next function <nova_core::vbios::FwSecBiosImage>::fwsec_header()
> 
> The code in concern is implementing try_from():
> +
> +impl TryFrom<BiosImageBase> for PciAtBiosImage {
> +    type Error = Error;
> +
> +    fn try_from(base: BiosImageBase) -> Result<Self> {
> 
> I dumped the codegen [2] for this function and at the end of the codegen, there
> is a call instruction to to the fwsec_header() function.
> 
> Any thoughts on how to fix the warning?

Btw, Danilo mentioned to me the latest Rust compiler (1.86?) does not give
this warning for that patch.

Mine is on 1.85. So if anyone else other than me is suffering from this
warning, do upgrade. :-)

thanks,

 - Joel

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[John Hubbard]

On 5/13/25 2:58 PM, Joel Fernandes wrote:
> On Tue, May 13, 2025 at 02:07:57PM -0400, Joel Fernandes wrote:
>> On Fri, May 02, 2025 at 04:02:33PM +0200, Miguel Ojeda wrote:
>>> Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report:
...
> Btw, Danilo mentioned to me the latest Rust compiler (1.86?) does not give
> this warning for that patch.

I'm sorry to burst this happy bubble, but I just upgraded to rustc 1.86 and did
a clean build, and I *am* setting these warnings:

$ rustc --version
rustc 1.86.0 (05f9846f8 2025-03-31) (Arch Linux rust 1:1.86.0-1)

...
  RUSTC L rust/kernel.o
rust/kernel.o: warning: objtool: _RNvMNtCsbA27Kl4nY2_6kernel6deviceNtB2_6Device10get_device() falls through to next function _RNvXs4_NtCsbA27Kl4nY2_6kernel9auxiliaryNtB5_6DeviceNtNtB7_5types16AlwaysRefCounted7inc_ref()
rust/kernel.o: warning: objtool: _RNvMs2_NtNtCsbA27Kl4nY2_6kernel2fs4fileNtB5_9LocalFile4cred() falls through to next function _RNvXs8_NtNtCsbA27Kl4nY2_6kernel2fs4fileNtB5_10BadFdErrorNtNtCs8y00iZOEpTQ_4core3fmt5Debug3fmt()

...followed by 10 or 12 more of the same "falls through" type.


> 
> Mine is on 1.85. So if anyone else other than me is suffering from this
> warning, do upgrade. :-)
> 

Looks like that might not suffice!

thanks,
-- 
John Hubbard

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Timur Tabi]

On Tue, 2025-05-13 at 17:22 -0700, John Hubbard wrote:
> On 5/13/25 2:58 PM, Joel Fernandes wrote:
> > On Tue, May 13, 2025 at 02:07:57PM -0400, Joel Fernandes wrote:
> > > On Fri, May 02, 2025 at 04:02:33PM +0200, Miguel Ojeda wrote:
> > > > Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report:
> ...
> > Btw, Danilo mentioned to me the latest Rust compiler (1.86?) does not give
> > this warning for that patch.
> 
> I'm sorry to burst this happy bubble, but I just upgraded to rustc 1.86 and did
> a clean build, and I *am* setting these warnings:

I see these warnings with .c code also:

  CHK     kernel/kheaders_data.tar.xz
drivers/media/pci/solo6x10/solo6x10-tw28.o: error: objtool: tw28_set_ctrl_val() falls through to
next function tw28_get_ctrl_val()
make[9]: *** [scripts/Makefile.build:203: drivers/media/pci/solo6x10/solo6x10-tw28.o] Error 1

I think it's an objtool bug and not a rustc bug.

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Joel Fernandes]

On 5/13/2025 8:43 PM, Timur Tabi wrote:
> On Tue, 2025-05-13 at 17:22 -0700, John Hubbard wrote:
>> On 5/13/25 2:58 PM, Joel Fernandes wrote:
>>> On Tue, May 13, 2025 at 02:07:57PM -0400, Joel Fernandes wrote:
>>>> On Fri, May 02, 2025 at 04:02:33PM +0200, Miguel Ojeda wrote:
>>>>> Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report:
>> ...
>>> Btw, Danilo mentioned to me the latest Rust compiler (1.86?) does not give
>>> this warning for that patch.
>>
>> I'm sorry to burst this happy bubble, but I just upgraded to rustc 1.86 and did
>> a clean build, and I *am* setting these warnings:
> 
> I see these warnings with .c code also:
> 
>   CHK     kernel/kheaders_data.tar.xz
> drivers/media/pci/solo6x10/solo6x10-tw28.o: error: objtool: tw28_set_ctrl_val() falls through to
> next function tw28_get_ctrl_val()
> make[9]: *** [scripts/Makefile.build:203: drivers/media/pci/solo6x10/solo6x10-tw28.o] Error 1
> 
> I think it's an objtool bug and not a rustc bug.

Thanks John and Timur.
And sigh, fwiw I pulled the latest rust nightly build and I see the warning as well:

rustc --version
rustc 1.89.0-nightly (414482f6a 2025-05-13)

I am leaning more towards Timur's opinion that this is more than likely an
objtool issue.

 - Joel

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Josh Poimboeuf]

On Wed, May 14, 2025 at 10:52:17AM -0400, Joel Fernandes wrote:
> On 5/13/2025 8:43 PM, Timur Tabi wrote:
> > On Tue, 2025-05-13 at 17:22 -0700, John Hubbard wrote:
> >> On 5/13/25 2:58 PM, Joel Fernandes wrote:
> >>> On Tue, May 13, 2025 at 02:07:57PM -0400, Joel Fernandes wrote:
> >>>> On Fri, May 02, 2025 at 04:02:33PM +0200, Miguel Ojeda wrote:
> >>>>> Starting with Rust 1.87.0 (expected 2025-05-15), `objtool` may report:
> >> ...
> >>> Btw, Danilo mentioned to me the latest Rust compiler (1.86?) does not give
> >>> this warning for that patch.
> >>
> >> I'm sorry to burst this happy bubble, but I just upgraded to rustc 1.86 and did
> >> a clean build, and I *am* setting these warnings:
> > 
> > I see these warnings with .c code also:
> > 
> >   CHK     kernel/kheaders_data.tar.xz
> > drivers/media/pci/solo6x10/solo6x10-tw28.o: error: objtool: tw28_set_ctrl_val() falls through to
> > next function tw28_get_ctrl_val()
> > make[9]: *** [scripts/Makefile.build:203: drivers/media/pci/solo6x10/solo6x10-tw28.o] Error 1
> > 
> > I think it's an objtool bug and not a rustc bug.
> 
> Thanks John and Timur.
> And sigh, fwiw I pulled the latest rust nightly build and I see the warning as well:
> 
> rustc --version
> rustc 1.89.0-nightly (414482f6a 2025-05-13)
> 
> I am leaning more towards Timur's opinion that this is more than likely an
> objtool issue.

The above warning is in completely different code from the Rust one, so
they're likely unrelated.

The fallthrough warnings are typically caused by either Clang undefined
behavior (usually potential divide by zero or negative shift), or a call
to an unannotated noreturn function.

Timur, can you share your .config and compiler version?

-- 
Josh

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Timur Tabi]

On Wed, 2025-05-14 at 12:14 -0700, Josh Poimboeuf wrote:
> The above warning is in completely different code from the Rust one, so
> they're likely unrelated.

True, but the fall-through is bogus in the C code as well.

> The fallthrough warnings are typically caused by either Clang undefined
> behavior (usually potential divide by zero or negative shift), or a call
> to an unannotated noreturn function.
> 
> Timur, can you share your .config and compiler version?

.config: https://pastebin.com/inDHfmbG

ttabi@ttabi:~$ llvm-config --version
18.1.3
ttabi@ttabi:~$ gcc --version
gcc (Ubuntu 14.2.0-4ubuntu2~24.04) 14.2.0

Since I build with LLVM=1, I'm assuming the answer is 18.1.3

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Josh Poimboeuf]

On Wed, May 14, 2025 at 07:46:49PM +0000, Timur Tabi wrote:
> On Wed, 2025-05-14 at 12:14 -0700, Josh Poimboeuf wrote:
> > The above warning is in completely different code from the Rust one, so
> > they're likely unrelated.
> 
> True, but the fall-through is bogus in the C code as well.
> 
> > The fallthrough warnings are typically caused by either Clang undefined
> > behavior (usually potential divide by zero or negative shift), or a call
> > to an unannotated noreturn function.
> > 
> > Timur, can you share your .config and compiler version?
> 
> .config: https://pastebin.com/inDHfmbG
> 
> ttabi@ttabi:~$ llvm-config --version
> 18.1.3
> ttabi@ttabi:~$ gcc --version
> gcc (Ubuntu 14.2.0-4ubuntu2~24.04) 14.2.0
> 
> Since I build with LLVM=1, I'm assuming the answer is 18.1.3

I'm not able to recreate, can you run with OBJTOOL_VERBOSE=1 and paste
the output?

-- 
Josh

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Timur Tabi]

On Thu, 2025-05-15 at 09:18 -0700, Josh Poimboeuf wrote:
> > Since I build with LLVM=1, I'm assuming the answer is 18.1.3
> 
> I'm not able to recreate, can you run with OBJTOOL_VERBOSE=1 and paste
> the output?

You probably can't repro because it includes code that hasn't been merged upstream yet.  Try this:

https://github.com/ttabi/linux/commits/alex

  CHK     kernel/kheaders_data.tar.xz
drivers/gpu/nova-core/nova_core.o: warning: objtool:
_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFro
mNtB5_13BiosImageBaseE8try_from() falls through to next function
_RNvMsd_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14FwSecBiosImage12fwsec_header()
drivers/gpu/nova-core/nova_core.o: warning: objtool:  
_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFro
mNtB5_13BiosImageBaseE8try_from+0x5c: (branch)
drivers/gpu/nova-core/nova_core.o: warning: objtool:  
_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFro
mNtB5_13BiosImageBaseE8try_from+0x4a: (branch)
drivers/gpu/nova-core/nova_core.o: warning: objtool:  
_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFro
mNtB5_13BiosImageBaseE8try_from+0x0: <=== (sym)
./tools/objtool/objtool --hacks=jump_label --hacks=noinstr --hacks=skylake --mcount --mnop --
retpoline --rethunk --sls --stackval --static-call --uaccess --prefix=16 --module drivers/gpu/nova-
core/nova_core.o.orig -o drivers/gpu/nova-core/nova_core.o
0000 0000000000006230
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from>:
0000     6230:	55                   	push   %rbp
0001     6231:	48 89 e5             	mov    %rsp,%rbp
0004     6234:	53                   	push   %rbx
0005     6235:	48 83 ec 18          	sub    $0x18,%rsp
0009     6239:	48 89 fb             	mov    %rdi,%rbx
000c     623c:	48 8b 3e             	mov    (%rsi),%rdi
000f     623f:	48 8b 4e 10          	mov    0x10(%rsi),%rcx
0013     6243:	c7 45 f2 ff b8 42 49 	movl   $0x4942b8ff,-0xe(%rbp)
001a     624a:	66 c7 45 f6 54 00    	movw   $0x54,-0xa(%rbp)
0020     6250:	48 83 f9 06          	cmp    $0x6,%rcx
0024     6254:	72 42                	jb     6298
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x68>
0026     6256:	48 8d 51 fb          	lea    -0x5(%rcx),%rdx
002a     625a:	31 c0                	xor    %eax,%eax
002c     625c:	0f 1f 40 00          	nopl   0x0(%rax)
0030     6260:	44 8b 04 07          	mov    (%rdi,%rax,1),%r8d
0034     6264:	44 33 45 f2          	xor    -0xe(%rbp),%r8d
0038     6268:	44 0f b7 4c 07 04    	movzwl 0x4(%rdi,%rax,1),%r9d
003e     626e:	66 44 33 4d f6       	xor    -0xa(%rbp),%r9w
0043     6273:	45 0f b7 c9          	movzwl %r9w,%r9d
0047     6277:	45 09 c1             	or     %r8d,%r9d
004a     627a:	74 0a                	je     6286
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x56>
004c     627c:	48 ff c0             	inc    %rax
004f     627f:	48 39 c2             	cmp    %rax,%rdx
0052     6282:	75 dc                	jne    6260
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x30>
0054     6284:	eb 12                	jmp    6298
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x68>
0056     6286:	48 89 ca             	mov    %rcx,%rdx
0059     6289:	48 29 c2             	sub    %rax,%rdx
005c     628c:	0f 82 ac 00 00 00    	jb     633e
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x10e>
0062     6292:	48 83 fa 0c          	cmp    $0xc,%rdx
0066     6296:	73 30                	jae    62c8
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x98>
0068     6298:	c7 43 08 ea ff ff ff 	movl   $0xffffffea,0x8(%rbx)
006f     629f:	48 c7 03 02 00 00 00 	movq   $0x2,(%rbx)
0076     62a6:	48 8b 46 08          	mov    0x8(%rsi),%rax
007a     62aa:	48 85 c0             	test   %rax,%rax
007d     62ad:	48 0f 44 f8          	cmove  %rax,%rdi
0081     62b1:	31 f6                	xor    %esi,%esi
0083     62b3:	31 d2                	xor    %edx,%edx
0085     62b5:	e8 00 00 00 00       	call   62ba
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x8a>	62b6: R_X86_64_PLT32	rust_helper_krealloc-0x4
008a     62ba:	48 89 d8             	mov    %rbx,%rax
008d     62bd:	48 83 c4 18          	add    $0x18,%rsp
0091     62c1:	5b                   	pop    %rbx
0092     62c2:	5d                   	pop    %rbp
0093     62c3:	e9 00 00 00 00       	jmp    62c8
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x98>	62c4: R_X86_64_PLT32	__x86_return_thunk-0x4
0098     62c8:	66 81 3c 07 ff b8    	cmpw   $0xb8ff,(%rdi,%rax,1)
009e     62ce:	75 c8                	jne    6298
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x68>
00a0     62d0:	81 7c 07 02 42 49 54 00 	cmpl   $0x544942,0x2(%rdi,%rax,1)
00a8     62d8:	75 be                	jne    6298
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x68>
00aa     62da:	0f b6 4c 07 0a       	movzbl 0xa(%rdi,%rax,1),%ecx
00af     62df:	8b 54 07 06          	mov    0x6(%rdi,%rax,1),%edx
00b3     62e3:	44 0f b6 44 07 0b    	movzbl 0xb(%rdi,%rax,1),%r8d
00b9     62e9:	c7 45 ec 42 49 54 00 	movl   $0x544942,-0x14(%rbp)
00c0     62f0:	66 c7 45 f0 ff b8    	movw   $0xb8ff,-0x10(%rbp)
00c6     62f6:	48 c1 e1 20          	shl    $0x20,%rcx
00ca     62fa:	49 c1 e0 28          	shl    $0x28,%r8
00ce     62fe:	49 09 c8             	or     %rcx,%r8
00d1     6301:	44 8b 4d ee          	mov    -0x12(%rbp),%r9d
00d5     6305:	48 c7 03 01 00 00 00 	movq   $0x1,(%rbx)
00dc     630c:	48 89 43 08          	mov    %rax,0x8(%rbx)
00e0     6310:	48 8d 7b 10          	lea    0x10(%rbx),%rdi
00e4     6314:	b9 0d 00 00 00       	mov    $0xd,%ecx
00e9     6319:	f3 48 a5             	rep movsq %ds:(%rsi),%es:(%rdi)
00ec     631c:	c7 43 78 01 00 42 49 	movl   $0x49420001,0x78(%rbx)
00f3     6323:	44 89 4b 7c          	mov    %r9d,0x7c(%rbx)
00f7     6327:	49 c1 e8 20          	shr    $0x20,%r8
00fb     632b:	66 44 89 83 84 00 00 00 	mov    %r8w,0x84(%rbx)
0103     6333:	89 93 80 00 00 00    	mov    %edx,0x80(%rbx)
0109     6339:	e9 7c ff ff ff       	jmp    62ba
<_RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFr
omNtB5_13BiosImageBaseE8try_from+0x8a>
010e     633e:	48 89 c7             	mov    %rax,%rdi
0111     6341:	48 89 ce             	mov    %rcx,%rsi
0114     6344:	48 c7 c2 00 00 00 00 	mov    $0x0,%rdx	6347:
R_X86_64_32S	.rodata+0x1058
011b     634b:	e8 00 00 00 00       	call   6350 <.Ltmp38>	634c:
R_X86_64_PLT32	_RNvNtNtCsgK88DPai1lC_4core5slice5index26slice_start_index_len_fail-0x4

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Kane York]

On Thu, 15 May 2025 19:06:10 +0000, Timur Tabi <ttabi@nvidia.com> wrote:
> On Thu, 2025-05-15 at 09:18 -0700, Josh Poimboeuf wrote:
> > > Since I build with LLVM=1, I'm assuming the answer is 18.1.3
> >
> > I'm not able to recreate, can you run with OBJTOOL_VERBOSE=1 and paste
> > the output?
>
> You probably can't repro because it includes code that hasn't been merged upstream yet.  Try this:
>
> https://github.com/ttabi/linux/commits/alex
>
>   CHK     kernel/kheaders_data.tar.xz
> drivers/gpu/nova-core/nova_core.o: warning: objtool:
> _RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFro
> mNtB5_13BiosImageBaseE8try_from() falls through to next function

...

> 011b     634b:	e8 00 00 00 00       	call   6350 <.Ltmp38>	634c:
> R_X86_64_PLT32
> _RNvNtNtCsgK88DPai1lC_4core5slice5index26slice_start_index_len_fail-0x4

Yup, that's an unrecognized noreturn function.

src/core/slice/index.rs:
> #[cfg_attr(not(feature = "panic_immediate_abort"), inline(never), cold)]
> #[cfg_attr(feature = "panic_immediate_abort", inline)]
> #[track_caller]
> #[rustc_const_unstable(feature = "const_slice_index", issue = "none")]
> const fn slice_start_index_len_fail(index: usize, len: usize) -> ! {
>     // SAFETY: we are just panicking here
>     unsafe {
>         const_eval_select(
>             (index, len),
>             slice_start_index_len_fail_ct,
>             slice_start_index_len_fail_rt,
>         )
>     }
> }
>
> // FIXME const-hack
> #[inline]
> #[track_caller]
> fn slice_start_index_len_fail_rt(index: usize, len: usize) -> ! {
>     panic!("range start index {index} out of range for slice of length {len}");
> }

The return is at offset 0093 (x62c3) with a jump to __x86_return_thunk.

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Josh Poimboeuf]

On Thu, May 15, 2025 at 07:06:10PM +0000, Timur Tabi wrote:
> On Thu, 2025-05-15 at 09:18 -0700, Josh Poimboeuf wrote:
> > > Since I build with LLVM=1, I'm assuming the answer is 18.1.3
> > 
> > I'm not able to recreate, can you run with OBJTOOL_VERBOSE=1 and paste
> > the output?
> 
> You probably can't repro because it includes code that hasn't been merged upstream yet.  Try this:
> 
> https://github.com/ttabi/linux/commits/alex
> 
>   CHK     kernel/kheaders_data.tar.xz
> drivers/gpu/nova-core/nova_core.o: warning: objtool:
> _RNvXsa_NtCs8S3917Wilyo_9nova_core5vbiosNtB5_14PciAtBiosImageINtNtCsgK88DPai1lC_4core7convert7TryFro

I'm not yet qualified to look at the rust warning, I was actually
wondering about the C one you reported:

  drivers/media/pci/solo6x10/solo6x10-tw28.o: error: objtool: tw28_set_ctrl_val() falls through to next function tw28_get_ctrl_val()

-- 
Josh

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Timur Tabi]

On Thu, 2025-05-15 at 15:16 -0700, Josh Poimboeuf wrote:
> I'm not yet qualified to look at the rust warning, I was actually
> wondering about the C one you reported:
> 
>   drivers/media/pci/solo6x10/solo6x10-tw28.o: error: objtool: tw28_set_ctrl_val() falls through to
> next function tw28_get_ctrl_val()

https://pastebin.com/DYuifnTB

Re: [PATCH 1/5] objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0

[Miguel Ojeda]

On Tue, May 13, 2025 at 8:08 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Any thoughts on how to fix the warning?

For future reference, this gets fixed with
https://lore.kernel.org/rust-for-linux/20250520185555.825242-1-ojeda@kernel.org/

I hope that helps (and apologies for the delay, a bunch of us were in
RustWeek :)

Cheers,
Miguel

[PATCH 2/5] rust: clean Rust 1.87.0's `clippy::ptr_eq` lints

[Miguel Ojeda]

Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand
the `ptr_eq` lint, e.g.:

    error: use `core::ptr::eq` when comparing raw pointers
       --> rust/kernel/list.rs:438:12
        |
    438 |         if self.first == item {
        |            ^^^^^^^^^^^^^^^^^^ help: try: `core::ptr::eq(self.first, item)`
        |
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq
        = note: `-D clippy::ptr-eq` implied by `-D warnings`
        = help: to override `-D warnings` add `#[allow(clippy::ptr_eq)]`

Thus clean the few cases we have.

This patch may not be actually needed by the time Rust 1.87.0 releases
since a PR to relax the lint has been beta nominated [2] due to reports
of being too eager (at least by default) [3].

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust-clippy/pull/14339 [1]
Link: https://github.com/rust-lang/rust-clippy/pull/14526 [2]
Link: https://github.com/rust-lang/rust-clippy/issues/14525 [3]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/kernel/alloc/kvec.rs |  2 +-
 rust/kernel/list.rs       | 12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs
index ae9d072741ce..cde911551327 100644
--- a/rust/kernel/alloc/kvec.rs
+++ b/rust/kernel/alloc/kvec.rs
@@ -743,7 +743,7 @@ fn into_raw_parts(self) -> (*mut T, NonNull<T>, usize, usize) {
     pub fn collect(self, flags: Flags) -> Vec<T, A> {
         let old_layout = self.layout;
         let (mut ptr, buf, len, mut cap) = self.into_raw_parts();
-        let has_advanced = ptr != buf.as_ptr();
+        let has_advanced = !core::ptr::eq(ptr, buf.as_ptr());
 
         if has_advanced {
             // Copy the contents we have advanced to at the beginning of the buffer.
diff --git a/rust/kernel/list.rs b/rust/kernel/list.rs
index a335c3b1ff5e..c63cbeee3316 100644
--- a/rust/kernel/list.rs
+++ b/rust/kernel/list.rs
@@ -435,7 +435,7 @@ unsafe fn remove_internal_inner(
         //  * If `item` was the only item in the list, then `prev == item`, and we just set
         //    `item->next` to null, so this correctly sets `first` to null now that the list is
         //    empty.
-        if self.first == item {
+        if core::ptr::eq(self.first, item) {
             // SAFETY: The `prev` pointer is the value that `item->prev` had when it was in this
             // list, so it must be valid. There is no race since `prev` is still in the list and we
             // still have exclusive access to the list.
@@ -556,7 +556,7 @@ fn next(&mut self) -> Option<ArcBorrow<'a, T>> {
         let next = unsafe { (*current).next };
         // INVARIANT: If `current` was the last element of the list, then this updates it to null.
         // Otherwise, we update it to the next element.
-        self.current = if next != self.stop {
+        self.current = if !core::ptr::eq(next, self.stop) {
             next
         } else {
             ptr::null_mut()
@@ -726,7 +726,7 @@ impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> Cursor<'a, T, ID> {
     fn prev_ptr(&self) -> *mut ListLinksFields {
         let mut next = self.next;
         let first = self.list.first;
-        if next == first {
+        if core::ptr::eq(next, first) {
             // We are before the first element.
             return core::ptr::null_mut();
         }
@@ -788,7 +788,7 @@ pub fn move_next(&mut self) -> bool {
         // access the `next` field.
         let mut next = unsafe { (*self.next).next };
 
-        if next == self.list.first {
+        if core::ptr::eq(next, self.list.first) {
             next = core::ptr::null_mut();
         }
 
@@ -802,7 +802,7 @@ pub fn move_next(&mut self) -> bool {
     /// If the cursor is before the first element, then this call does nothing. This call returns
     /// `true` if the cursor's position was changed.
     pub fn move_prev(&mut self) -> bool {
-        if self.next == self.list.first {
+        if core::ptr::eq(self.next, self.list.first) {
             return false;
         }
 
@@ -822,7 +822,7 @@ fn insert_inner(&mut self, item: ListArc<T, ID>) -> *mut ListLinksFields {
         // * `ptr` is an element in the list or null.
         // * if `ptr` is null, then `self.list.first` is null so the list is empty.
         let item = unsafe { self.list.insert_inner(item, ptr) };
-        if self.next == self.list.first {
+        if core::ptr::eq(self.next, self.list.first) {
             // INVARIANT: We just inserted `item`, so it's a member of list.
             self.list.first = item;
         }
-- 
2.49.0

Re: [PATCH 2/5] rust: clean Rust 1.87.0's `clippy::ptr_eq` lints

[Alice Ryhl]

On Fri, May 02, 2025 at 04:02:34PM +0200, Miguel Ojeda wrote:
> Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand
> the `ptr_eq` lint, e.g.:
> 
>     error: use `core::ptr::eq` when comparing raw pointers
>        --> rust/kernel/list.rs:438:12
>         |
>     438 |         if self.first == item {
>         |            ^^^^^^^^^^^^^^^^^^ help: try: `core::ptr::eq(self.first, item)`
>         |
>         = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq
>         = note: `-D clippy::ptr-eq` implied by `-D warnings`
>         = help: to override `-D warnings` add `#[allow(clippy::ptr_eq)]`
> 
> Thus clean the few cases we have.
> 
> This patch may not be actually needed by the time Rust 1.87.0 releases
> since a PR to relax the lint has been beta nominated [2] due to reports
> of being too eager (at least by default) [3].
> 
> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
> Link: https://github.com/rust-lang/rust-clippy/pull/14339 [1]
> Link: https://github.com/rust-lang/rust-clippy/pull/14526 [2]
> Link: https://github.com/rust-lang/rust-clippy/issues/14525 [3]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

For the list file, it might be nice to import core::ptr instead of using
the full path each time. Or maybe just disable this lint.

Alice

Re: [PATCH 2/5] rust: clean Rust 1.87.0's `clippy::ptr_eq` lints

[Miguel Ojeda]

On Mon, May 5, 2025 at 11:23 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> For the list file, it might be nice to import core::ptr instead of using
> the full path each time. Or maybe just disable this lint.

Since they confirmed they will backport it, I will disable it locally
when applying so that it is a smaller change, and then we can
remove/revert the `allow` afterwards if all goes well.

For the other one, it is a single line already anyway, so it does not
matter much.

Cheers,
Miguel

[PATCH 3/5] rust: clean Rust 1.88.0's `unnecessary_transmutes` lint

[Miguel Ojeda]

Starting with Rust 1.88.0 (expected 2025-06-26) [1][2], `rustc` may
introduce a new lint that catches unnecessary transmutes, e.g.:

     error: unnecessary transmute
         --> rust/uapi/uapi_generated.rs:23242:18
          |
    23242 |         unsafe { ::core::mem::transmute(self._bitfield_1.get(0usize, 1u8) as u8) }
          |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this with: `(self._bitfield_1.get(0usize, 1u8) as u8 == 1)`
          |
          = note: `-D unnecessary-transmutes` implied by `-D warnings`
          = help: to override `-D warnings` add `#[allow(unnecessary_transmutes)]`

There are a lot of them (at least 300), but luckily they are all in
`bindgen`-generated code.

Thus clean all up by allowing it there.

Since unknown lints trigger a lint itself in older compilers, do it
conditionally so that we can keep the `unknown_lints` lint enabled.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust/pull/136083 [1]
Link: https://github.com/rust-lang/rust/issues/136067 [2]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 init/Kconfig         | 3 +++
 rust/bindings/lib.rs | 1 +
 rust/uapi/lib.rs     | 1 +
 3 files changed, 5 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 63f5974b9fa6..4cdd1049283c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -140,6 +140,9 @@ config LD_CAN_USE_KEEP_IN_OVERLAY
 config RUSTC_HAS_COERCE_POINTEE
 	def_bool RUSTC_VERSION >= 108400
 
+config RUSTC_HAS_UNNECESSARY_TRANSMUTES
+	def_bool RUSTC_VERSION >= 108800
+
 config PAHOLE_VERSION
 	int
 	default $(shell,$(srctree)/scripts/pahole-version.sh $(PAHOLE))
diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs
index 014af0d1fc70..a08eb5518cac 100644
--- a/rust/bindings/lib.rs
+++ b/rust/bindings/lib.rs
@@ -26,6 +26,7 @@
 
 #[allow(dead_code)]
 #[allow(clippy::undocumented_unsafe_blocks)]
+#[cfg_attr(CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES, allow(unnecessary_transmutes))]
 mod bindings_raw {
     // Manual definition for blocklisted types.
     type __kernel_size_t = usize;
diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs
index 13495910271f..c98d7a8cde77 100644
--- a/rust/uapi/lib.rs
+++ b/rust/uapi/lib.rs
@@ -24,6 +24,7 @@
     unreachable_pub,
     unsafe_op_in_unsafe_fn
 )]
+#![cfg_attr(CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES, allow(unnecessary_transmutes))]
 
 // Manual definition of blocklisted types.
 type __kernel_size_t = usize;
-- 
2.49.0

[PATCH 4/5] rust: clean Rust 1.88.0's warning about `clippy::disallowed_macros` configuration

[Miguel Ojeda]

Starting with Rust 1.88.0 (expected 2025-06-26) [1], Clippy may start
warning about paths that do not resolve in the `disallowed_macros`
configuration:

    warning: `kernel::dbg` does not refer to an existing macro
      --> .clippy.toml:10:5
       |
    10 |     { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" },
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is a lint we requested at [2], due to the trouble debugging
the lint due to false negatives (e.g. [3]), which we use to emulate
`clippy::dbg_macro` [4]. See commit 8577c9dca799 ("rust: replace
`clippy::dbg_macro` with `disallowed_macros`") for more details.

Given the false negatives are not resolved yet, it is expected that
Clippy complains about not finding this macro.

Thus, until the false negatives are fixed (and, even then, probably we
will need to wait for the MSRV to raise enough), use the escape hatch
to allow an invalid path.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust-clippy/pull/14397 [1]
Link: https://github.com/rust-lang/rust-clippy/issues/11432 [2]
Link: https://github.com/rust-lang/rust-clippy/issues/11431 [3]
Link: https://github.com/rust-lang/rust-clippy/issues/11303 [4]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 .clippy.toml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.clippy.toml b/.clippy.toml
index 815c94732ed7..137f41d203de 100644
--- a/.clippy.toml
+++ b/.clippy.toml
@@ -7,5 +7,5 @@ check-private-items = true
 disallowed-macros = [
     # The `clippy::dbg_macro` lint only works with `std::dbg!`, thus we simulate
     # it here, see: https://github.com/rust-lang/rust-clippy/issues/11303.
-    { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" },
+    { path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool", allow-invalid = true },
 ]
-- 
2.49.0

[PATCH 5/5] rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

[Miguel Ojeda]

Starting with Rust 1.88.0 (expected 2025-06-26) [1], `rustc` may move
back the `uninlined_format_args` to `style` from `pedantic` (it was
there waiting for rust-analyzer suppotr), and thus we will start to see
lints like:

    warning: variables can be used directly in the `format!` string
       --> rust/macros/kunit.rs:105:37
        |
    105 |         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
        |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        |
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
    help: change this to
        |
    105 -         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
    105 +         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}");

There is even a case that is a pure removal:

    warning: variables can be used directly in the `format!` string
      --> rust/macros/module.rs:51:13
       |
    51 |             format!("{field}={content}\0", field = field, content = content)
       |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       |
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
    help: change this to
       |
    51 -             format!("{field}={content}\0", field = field, content = content)
    51 +             format!("{field}={content}\0")

The lints all seem like nice cleanups, thus just apply them.

We may want to disable `allow-mixed-uninlined-format-args` in the future.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Benno Lossin <benno.lossin@proton.me>
Link: https://github.com/rust-lang/rust-clippy/pull/14160 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 drivers/gpu/nova-core/gpu.rs              |  2 +-
 rust/kernel/str.rs                        | 46 +++++++++++------------
 rust/macros/kunit.rs                      | 13 ++-----
 rust/macros/module.rs                     | 19 +++-------
 rust/macros/paste.rs                      |  2 +-
 rust/pin-init/internal/src/pinned_drop.rs |  3 +-
 6 files changed, 35 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 17c9660da450..ab0e5a72a059 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -93,7 +93,7 @@ pub(crate) fn arch(&self) -> Architecture {
 // For now, redirect to fmt::Debug for convenience.
 impl fmt::Display for Chipset {
     fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
-        write!(f, "{:?}", self)
+        write!(f, "{self:?}")
     }
 }

diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
index 878111cb77bc..fb61ce81ea28 100644
--- a/rust/kernel/str.rs
+++ b/rust/kernel/str.rs
@@ -73,7 +73,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
                 b'\r' => f.write_str("\\r")?,
                 // Printable characters.
                 0x20..=0x7e => f.write_char(b as char)?,
-                _ => write!(f, "\\x{:02x}", b)?,
+                _ => write!(f, "\\x{b:02x}")?,
             }
         }
         Ok(())
@@ -109,7 +109,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
                 b'\\' => f.write_str("\\\\")?,
                 // Printable characters.
                 0x20..=0x7e => f.write_char(b as char)?,
-                _ => write!(f, "\\x{:02x}", b)?,
+                _ => write!(f, "\\x{b:02x}")?,
             }
         }
         f.write_char('"')
@@ -447,7 +447,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
                 // Printable character.
                 f.write_char(c as char)?;
             } else {
-                write!(f, "\\x{:02x}", c)?;
+                write!(f, "\\x{c:02x}")?;
             }
         }
         Ok(())
@@ -479,7 +479,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
                 // Printable characters.
                 b'\"' => f.write_str("\\\"")?,
                 0x20..=0x7e => f.write_char(c as char)?,
-                _ => write!(f, "\\x{:02x}", c)?,
+                _ => write!(f, "\\x{c:02x}")?,
             }
         }
         f.write_str("\"")
@@ -641,13 +641,13 @@ fn test_cstr_as_str_unchecked() {
     #[test]
     fn test_cstr_display() {
         let hello_world = CStr::from_bytes_with_nul(b"hello, world!\0").unwrap();
-        assert_eq!(format!("{}", hello_world), "hello, world!");
+        assert_eq!(format!("{hello_world}"), "hello, world!");
         let non_printables = CStr::from_bytes_with_nul(b"\x01\x09\x0a\0").unwrap();
-        assert_eq!(format!("{}", non_printables), "\\x01\\x09\\x0a");
+        assert_eq!(format!("{non_printables}"), "\\x01\\x09\\x0a");
         let non_ascii = CStr::from_bytes_with_nul(b"d\xe9j\xe0 vu\0").unwrap();
-        assert_eq!(format!("{}", non_ascii), "d\\xe9j\\xe0 vu");
+        assert_eq!(format!("{non_ascii}"), "d\\xe9j\\xe0 vu");
         let good_bytes = CStr::from_bytes_with_nul(b"\xf0\x9f\xa6\x80\0").unwrap();
-        assert_eq!(format!("{}", good_bytes), "\\xf0\\x9f\\xa6\\x80");
+        assert_eq!(format!("{good_bytes}"), "\\xf0\\x9f\\xa6\\x80");
     }

     #[test]
@@ -658,47 +658,47 @@ fn test_cstr_display_all_bytes() {
             bytes[i as usize] = i.wrapping_add(1);
         }
         let cstr = CStr::from_bytes_with_nul(&bytes).unwrap();
-        assert_eq!(format!("{}", cstr), ALL_ASCII_CHARS);
+        assert_eq!(format!("{cstr}"), ALL_ASCII_CHARS);
     }

     #[test]
     fn test_cstr_debug() {
         let hello_world = CStr::from_bytes_with_nul(b"hello, world!\0").unwrap();
-        assert_eq!(format!("{:?}", hello_world), "\"hello, world!\"");
+        assert_eq!(format!("{hello_world:?}"), "\"hello, world!\"");
         let non_printables = CStr::from_bytes_with_nul(b"\x01\x09\x0a\0").unwrap();
-        assert_eq!(format!("{:?}", non_printables), "\"\\x01\\x09\\x0a\"");
+        assert_eq!(format!("{non_printables:?}"), "\"\\x01\\x09\\x0a\"");
         let non_ascii = CStr::from_bytes_with_nul(b"d\xe9j\xe0 vu\0").unwrap();
-        assert_eq!(format!("{:?}", non_ascii), "\"d\\xe9j\\xe0 vu\"");
+        assert_eq!(format!("{non_ascii:?}"), "\"d\\xe9j\\xe0 vu\"");
         let good_bytes = CStr::from_bytes_with_nul(b"\xf0\x9f\xa6\x80\0").unwrap();
-        assert_eq!(format!("{:?}", good_bytes), "\"\\xf0\\x9f\\xa6\\x80\"");
+        assert_eq!(format!("{good_bytes:?}"), "\"\\xf0\\x9f\\xa6\\x80\"");
     }

     #[test]
     fn test_bstr_display() {
         let hello_world = BStr::from_bytes(b"hello, world!");
-        assert_eq!(format!("{}", hello_world), "hello, world!");
+        assert_eq!(format!("{hello_world}"), "hello, world!");
         let escapes = BStr::from_bytes(b"_\t_\n_\r_\\_\'_\"_");
-        assert_eq!(format!("{}", escapes), "_\\t_\\n_\\r_\\_'_\"_");
+        assert_eq!(format!("{escapes}"), "_\\t_\\n_\\r_\\_'_\"_");
         let others = BStr::from_bytes(b"\x01");
-        assert_eq!(format!("{}", others), "\\x01");
+        assert_eq!(format!("{others}"), "\\x01");
         let non_ascii = BStr::from_bytes(b"d\xe9j\xe0 vu");
-        assert_eq!(format!("{}", non_ascii), "d\\xe9j\\xe0 vu");
+        assert_eq!(format!("{non_ascii}"), "d\\xe9j\\xe0 vu");
         let good_bytes = BStr::from_bytes(b"\xf0\x9f\xa6\x80");
-        assert_eq!(format!("{}", good_bytes), "\\xf0\\x9f\\xa6\\x80");
+        assert_eq!(format!("{good_bytes}"), "\\xf0\\x9f\\xa6\\x80");
     }

     #[test]
     fn test_bstr_debug() {
         let hello_world = BStr::from_bytes(b"hello, world!");
-        assert_eq!(format!("{:?}", hello_world), "\"hello, world!\"");
+        assert_eq!(format!("{hello_world:?}"), "\"hello, world!\"");
         let escapes = BStr::from_bytes(b"_\t_\n_\r_\\_\'_\"_");
-        assert_eq!(format!("{:?}", escapes), "\"_\\t_\\n_\\r_\\\\_'_\\\"_\"");
+        assert_eq!(format!("{escapes:?}"), "\"_\\t_\\n_\\r_\\\\_'_\\\"_\"");
         let others = BStr::from_bytes(b"\x01");
-        assert_eq!(format!("{:?}", others), "\"\\x01\"");
+        assert_eq!(format!("{others:?}"), "\"\\x01\"");
         let non_ascii = BStr::from_bytes(b"d\xe9j\xe0 vu");
-        assert_eq!(format!("{:?}", non_ascii), "\"d\\xe9j\\xe0 vu\"");
+        assert_eq!(format!("{non_ascii:?}"), "\"d\\xe9j\\xe0 vu\"");
         let good_bytes = BStr::from_bytes(b"\xf0\x9f\xa6\x80");
-        assert_eq!(format!("{:?}", good_bytes), "\"\\xf0\\x9f\\xa6\\x80\"");
+        assert_eq!(format!("{good_bytes:?}"), "\"\\xf0\\x9f\\xa6\\x80\"");
     }
 }

diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
index 4f553ecf40c0..99ccac82edde 100644
--- a/rust/macros/kunit.rs
+++ b/rust/macros/kunit.rs
@@ -15,10 +15,7 @@ pub(crate) fn kunit_tests(attr: TokenStream, ts: TokenStream) -> TokenStream {
     }

     if attr.len() > 255 {
-        panic!(
-            "The test suite name `{}` exceeds the maximum length of 255 bytes",
-            attr
-        )
+        panic!("The test suite name `{attr}` exceeds the maximum length of 255 bytes")
     }

     let mut tokens: Vec<_> = ts.into_iter().collect();
@@ -102,16 +99,14 @@ pub(crate) fn kunit_tests(attr: TokenStream, ts: TokenStream) -> TokenStream {
     let mut kunit_macros = "".to_owned();
     let mut test_cases = "".to_owned();
     for test in &tests {
-        let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
+        let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}");
         let kunit_wrapper = format!(
-            "unsafe extern \"C\" fn {}(_test: *mut kernel::bindings::kunit) {{ {}(); }}",
-            kunit_wrapper_fn_name, test
+            "unsafe extern \"C\" fn {kunit_wrapper_fn_name}(_test: *mut kernel::bindings::kunit) {{ {test}(); }}"
         );
         writeln!(kunit_macros, "{kunit_wrapper}").unwrap();
         writeln!(
             test_cases,
-            "    kernel::kunit::kunit_case(kernel::c_str!(\"{}\"), {}),",
-            test, kunit_wrapper_fn_name
+            "    kernel::kunit::kunit_case(kernel::c_str!(\"{test}\"), {kunit_wrapper_fn_name}),"
         )
         .unwrap();
     }
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index a9418fbc9b44..2f66107847f7 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -48,7 +48,7 @@ fn emit_base(&mut self, field: &str, content: &str, builtin: bool) {
             )
         } else {
             // Loadable modules' modinfo strings go as-is.
-            format!("{field}={content}\0", field = field, content = content)
+            format!("{field}={content}\0")
         };

         write!(
@@ -126,10 +126,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
             };

             if seen_keys.contains(&key) {
-                panic!(
-                    "Duplicated key \"{}\". Keys can only be specified once.",
-                    key
-                );
+                panic!("Duplicated key \"{key}\". Keys can only be specified once.");
             }

             assert_eq!(expect_punct(it), ':');
@@ -143,10 +140,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
                 "license" => info.license = expect_string_ascii(it),
                 "alias" => info.alias = Some(expect_string_array(it)),
                 "firmware" => info.firmware = Some(expect_string_array(it)),
-                _ => panic!(
-                    "Unknown key \"{}\". Valid keys are: {:?}.",
-                    key, EXPECTED_KEYS
-                ),
+                _ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
             }

             assert_eq!(expect_punct(it), ',');
@@ -158,7 +152,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {

         for key in REQUIRED_KEYS {
             if !seen_keys.iter().any(|e| e == key) {
-                panic!("Missing required key \"{}\".", key);
+                panic!("Missing required key \"{key}\".");
             }
         }

@@ -170,10 +164,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
         }

         if seen_keys != ordered_keys {
-            panic!(
-                "Keys are not ordered as expected. Order them like: {:?}.",
-                ordered_keys
-            );
+            panic!("Keys are not ordered as expected. Order them like: {ordered_keys:?}.");
         }

         info
diff --git a/rust/macros/paste.rs b/rust/macros/paste.rs
index 6529a387673f..cce712d19855 100644
--- a/rust/macros/paste.rs
+++ b/rust/macros/paste.rs
@@ -50,7 +50,7 @@ fn concat_helper(tokens: &[TokenTree]) -> Vec<(String, Span)> {
                 let tokens = group.stream().into_iter().collect::<Vec<TokenTree>>();
                 segments.append(&mut concat_helper(tokens.as_slice()));
             }
-            token => panic!("unexpected token in paste segments: {:?}", token),
+            token => panic!("unexpected token in paste segments: {token:?}"),
         };
     }

diff --git a/rust/pin-init/internal/src/pinned_drop.rs b/rust/pin-init/internal/src/pinned_drop.rs
index c824dd8b436d..c4ca7a70b726 100644
--- a/rust/pin-init/internal/src/pinned_drop.rs
+++ b/rust/pin-init/internal/src/pinned_drop.rs
@@ -28,8 +28,7 @@ pub(crate) fn pinned_drop(_args: TokenStream, input: TokenStream) -> TokenStream
             // Found the end of the generics, this should be `PinnedDrop`.
             assert!(
                 matches!(tt, TokenTree::Ident(i) if i.to_string() == "PinnedDrop"),
-                "expected 'PinnedDrop', found: '{:?}'",
-                tt
+                "expected 'PinnedDrop', found: '{tt:?}'"
             );
             pinned_drop_idx = Some(i);
             break;
--
2.49.0

Re: [PATCH 5/5] rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

[Tamir Duberstein]

On Fri, May 2, 2025 at 7:04 AM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> Starting with Rust 1.88.0 (expected 2025-06-26) [1], `rustc` may move
> back the `uninlined_format_args` to `style` from `pedantic` (it was
> there waiting for rust-analyzer suppotr), and thus we will start to see

Typo: s/suppotr/support/

> lints like:
>
>     warning: variables can be used directly in the `format!` string
>        --> rust/macros/kunit.rs:105:37
>         |
>     105 |         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
>         |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         |
>         = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
>     help: change this to
>         |
>     105 -         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
>     105 +         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}");
>
> There is even a case that is a pure removal:
>
>     warning: variables can be used directly in the `format!` string
>       --> rust/macros/module.rs:51:13
>        |
>     51 |             format!("{field}={content}\0", field = field, content = content)
>        |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        |
>        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
>     help: change this to
>        |
>     51 -             format!("{field}={content}\0", field = field, content = content)
>     51 +             format!("{field}={content}\0")
>
> The lints all seem like nice cleanups, thus just apply them.
>
> We may want to disable `allow-mixed-uninlined-format-args` in the future.
>
> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
> Cc: Benno Lossin <benno.lossin@proton.me>
> Link: https://github.com/rust-lang/rust-clippy/pull/14160 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  drivers/gpu/nova-core/gpu.rs              |  2 +-
>  rust/kernel/str.rs                        | 46 +++++++++++------------
>  rust/macros/kunit.rs                      | 13 ++-----
>  rust/macros/module.rs                     | 19 +++-------
>  rust/macros/paste.rs                      |  2 +-
>  rust/pin-init/internal/src/pinned_drop.rs |  3 +-
>  6 files changed, 35 insertions(+), 50 deletions(-)

Reviewed-by: Tamir Duberstein <tamird@gmail.com>

Re: [PATCH 5/5] rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

[Benno Lossin]

On Fri May 2, 2025 at 4:02 PM CEST, Miguel Ojeda wrote:
> Starting with Rust 1.88.0 (expected 2025-06-26) [1], `rustc` may move
> back the `uninlined_format_args` to `style` from `pedantic` (it was
> there waiting for rust-analyzer suppotr), and thus we will start to see
> lints like:
>
>     warning: variables can be used directly in the `format!` string
>        --> rust/macros/kunit.rs:105:37
>         |
>     105 |         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
>         |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         |
>         = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
>     help: change this to
>         |
>     105 -         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
>     105 +         let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}");
>
> There is even a case that is a pure removal:
>
>     warning: variables can be used directly in the `format!` string
>       --> rust/macros/module.rs:51:13
>        |
>     51 |             format!("{field}={content}\0", field = field, content = content)
>        |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        |
>        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
>     help: change this to
>        |
>     51 -             format!("{field}={content}\0", field = field, content = content)
>     51 +             format!("{field}={content}\0")
>
> The lints all seem like nice cleanups, thus just apply them.
>
> We may want to disable `allow-mixed-uninlined-format-args` in the future.
>
> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
> Cc: Benno Lossin <benno.lossin@proton.me>
> Link: https://github.com/rust-lang/rust-clippy/pull/14160 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

For the pin-init modification: 

Acked-by: Benno Lossin <lossin@kernel.org>

---
Cheers,
Benno

> ---
>  drivers/gpu/nova-core/gpu.rs              |  2 +-
>  rust/kernel/str.rs                        | 46 +++++++++++------------
>  rust/macros/kunit.rs                      | 13 ++-----
>  rust/macros/module.rs                     | 19 +++-------
>  rust/macros/paste.rs                      |  2 +-
>  rust/pin-init/internal/src/pinned_drop.rs |  3 +-
>  6 files changed, 35 insertions(+), 50 deletions(-)

Re: [PATCH 0/5] Rust beta (1.87) and nightly (1.88) lint cleanups

[Alice Ryhl]

On Fri, May 02, 2025 at 04:02:32PM +0200, Miguel Ojeda wrote:
> Now that Rust 1.87.0 is close to release, clean up the new lints that appeared.
> 
> It may be that one of the patches is not needed by the time it releases, but
> I prefer to not wait much longer since I would like to land this for -rc6 so
> that it is clean for release.
> 
> In addition, clean some nightly (1.88.0) ones too.
> 
> Miguel Ojeda (5):
>   objtool/rust: add one more `noreturn` Rust function for Rust 1.87.0
>   rust: clean Rust 1.87.0's `clippy::ptr_eq` lints
>   rust: clean Rust 1.88.0's `unnecessary_transmutes` lint
>   rust: clean Rust 1.88.0's warning about `clippy::disallowed_macros`
>     configuration
>   rust: clean Rust 1.88.0's `clippy::uninlined_format_args` lint

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

Re: [PATCH 0/5] Rust beta (1.87) and nightly (1.88) lint cleanups

[Miguel Ojeda]

On Fri, May 2, 2025 at 4:03 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> Now that Rust 1.87.0 is close to release, clean up the new lints that appeared.
>
> It may be that one of the patches is not needed by the time it releases, but
> I prefer to not wait much longer since I would like to land this for -rc6 so
> that it is clean for release.
>
> In addition, clean some nightly (1.88.0) ones too.

Applied to `rust-fixes` -- thanks everyone!

    [ Converted to `allow`s since backport was confirmed. - Miguel ]

Cheers,
Miguel