linux-stable.git/rust/kernel, branch v7.2.4 Linux kernel stable tree rust: num: reject Bounded::shr overshifts at build time 2026-09-07T15:37:23+00:00 Eliot Courtney ecourtney@nvidia.com 2026-09-03T11:01:33+00:00 ceab9302388b22baa11c08386f3a04315baf1593 [ Upstream commit 223aa25aee82e188ddf043a8703b16e5fdfc37d8 ] Make `shr` reject shifts of at least the type's bit width at build time, instead of panicking or masking the shift amount at runtime. [ This implies we can break the type invariant, which in turn means we can trigger UB via `Deref`, e.g.: rust_kernel: panicked at rust/kernel/num/bounded.rs:528:22: unsafe precondition(s) violated: hint::unreachable_unchecked must never be reached - Miguel ] Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Cc: stable@vger.kernel.org Fixes: c59a2d14cd24 ("rust: num: add `shr` and `shl` methods to `Bounded`") Link: https://patch.msgid.link/20260810-pramin-split-v2-2-65a00b3c7309@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 223aa25aee82e188ddf043a8703b16e5fdfc37d8 ]

Make `shr` reject shifts of at least the type's bit width at build
time, instead of panicking or masking the shift amount at runtime.

[ This implies we can break the type invariant, which in turn means
  we can trigger UB via `Deref`, e.g.:

      rust_kernel: panicked at rust/kernel/num/bounded.rs:528:22:
      unsafe precondition(s) violated: hint::unreachable_unchecked must never be reached

    - Miguel ]

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Cc: stable@vger.kernel.org
Fixes: c59a2d14cd24 ("rust: num: add `shr` and `shl` methods to `Bounded`")
Link: https://patch.msgid.link/20260810-pramin-split-v2-2-65a00b3c7309@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: num: restrict bool conversion to unsigned Bounded 2026-09-07T15:36:31+00:00 Younes Akhouayri git@younes.io 2026-08-22T08:44:47+00:00 9d9b98b396099a5ae4ba7399311e100c17704d64 commit 7dd6343fc127935425a81a8f1989907996c2868d upstream. From<bool> turns true into 1. A signed Bounded with N = 1 can hold only -1 and 0. The current implementation can therefore create a value that breaks Bounded's invariant. Deref relies on that invariant and calls unreachable_unchecked() when it is broken, so safe Rust can reach undefined behavior. The other primitive conversions require the source and destination to have the same signedness. Treat bool as an unsigned one-bit value and allow conversions between bool and Bounded only when the backing integer type is unsigned. Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type") Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/ Cc: stable@vger.kernel.org Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Younes Akhouayri <git@younes.io> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7dd6343fc127935425a81a8f1989907996c2868d upstream.

From<bool> turns true into 1. A signed Bounded with N = 1 can hold
only -1 and 0. The current implementation can therefore create a value
that breaks Bounded's invariant. Deref relies on that invariant and
calls unreachable_unchecked() when it is broken, so safe Rust can reach
undefined behavior.

The other primitive conversions require the source and destination to
have the same signedness. Treat bool as an unsigned one-bit value and
allow conversions between bool and Bounded only when the backing integer
type is unsigned.

Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type")
Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/
Cc: stable@vger.kernel.org
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Younes Akhouayri <git@younes.io>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: kernel: list: fix incorrect pop_back example comment 2026-09-07T15:36:31+00:00 Nikolai Grlica nikolai@nikolaigrlica.dev 2026-08-10T15:03:35+00:00 744794d8920e99deac63c6ddb3ddedd4c625a6f9 commit a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c upstream. The example uses pop_back(), but the accompanying comment says pop_front(). Update the comment to match the example. Signed-off-by: Nikolai Grlica <nikolai@nikolaigrlica.dev> Cc: stable@vger.kernel.org Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage") Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a5c7d35e2fd3e24c411816c91f8f6cc78e652e0c upstream.

The example uses pop_back(), but the accompanying comment says
pop_front(). Update the comment to match the example.

Signed-off-by: Nikolai Grlica <nikolai@nikolaigrlica.dev>
Cc: stable@vger.kernel.org
Fixes: bf87a41b85d6 ("rust: list: Add an example for `ListLinksSelfPtr` usage")
Link: https://patch.msgid.link/20260810150322.61809-1-nikolai@nikolaigrlica.dev
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: devres: ensure revocation is complete before device finishes unbinding 2026-09-07T15:36:31+00:00 Danilo Krummrich dakr@kernel.org 2026-06-28T20:02:53+00:00 cdbbcd7c64c9d4dc8d1a47e34cb16db90fbc5a13 commit a10639966fd72fff8f7fbf3c8e733307daabd38f upstream. Now that the revocation Completion is in place, also address the symmetric case. When Devres::drop() wins the is_available swap and the devres callback loses, the callback returns to devres_release_all() without waiting. This means device unbinding can complete while Devres::drop() is still executing drop_in_place() on another CPU, which is a problem if T's destructor accesses device state. Make the synchronization bidirectional. Whichever side performs drop_in_place() signals the Completion, and the other side waits. This does not reintroduce the nested Devres deadlock fixed by commit ba268514ea14 ("rust: devres: fix race condition due to nesting"), because that deadlock was caused by drop waiting for the release callback to return (the old 'devm' Completion). Here, both sides only wait for drop_in_place() to finish, which completes within the current call chain. The Arc<Inner<T>> keeps the Inner allocation alive independently. Cc: stable@vger.kernel.org Fixes: ba268514ea14 ("rust: devres: fix race condition due to nesting") Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260628200304.2365598-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a10639966fd72fff8f7fbf3c8e733307daabd38f upstream.

Now that the revocation Completion is in place, also address the
symmetric case. When Devres::drop() wins the is_available swap and the
devres callback loses, the callback returns to devres_release_all()
without waiting. This means device unbinding can complete while
Devres::drop() is still executing drop_in_place() on another CPU, which
is a problem if T's destructor accesses device state.

Make the synchronization bidirectional. Whichever side performs
drop_in_place() signals the Completion, and the other side waits.

This does not reintroduce the nested Devres deadlock fixed by commit
ba268514ea14 ("rust: devres: fix race condition due to nesting"),
because that deadlock was caused by drop waiting for the release
callback to return (the old 'devm' Completion). Here, both sides only
wait for drop_in_place() to finish, which completes within the current
call chain. The Arc<Inner<T>> keeps the Inner allocation alive
independently.

Cc: stable@vger.kernel.org
Fixes: ba268514ea14 ("rust: devres: fix race condition due to nesting")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260628200304.2365598-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: devres: fix race between concurrent revokers 2026-09-07T15:36:31+00:00 Danilo Krummrich dakr@kernel.org 2026-06-28T17:44:38+00:00 c7e3d57c705ab1053a6a1bbef96795e792da1540 commit acc516dfa1972d31836b50abc0115216cd0fccc5 upstream. There is a potential race condition when two paths try to revoke a Devres concurrently. The driver core's devres_release_all() calls Revocable::revoke() via the release callback, while Devres::drop() calls revoke_nosync() on another CPU. The revoker that does not claim the is_available swap returns immediately, but the revoker that did may still be executing drop_in_place() on the inner data. This can cause a use-after-free when the other revoker's caller proceeds to drop adjacent resources that drop_in_place() still references (e.g., Devres<DmaMappedSgt> racing with SGTable freeing the backing sg_table and pages). Fix this by adding a Completion. The release callback signals the Completion after revoke() finishes, and Devres::drop() waits for it when it loses the is_available swap. This ensures the wrapped object is fully torn down before Devres::drop() returns. Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/dri-devel/20260612202841.2577C1F000E9@smtp.kernel.org/ Fixes: 05aa6fb1c21d ("rust: scatterlist: Add abstraction for sg_table") Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260628174451.2275679-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit acc516dfa1972d31836b50abc0115216cd0fccc5 upstream.

There is a potential race condition when two paths try to revoke a
Devres concurrently.

The driver core's devres_release_all() calls Revocable::revoke() via the
release callback, while Devres::drop() calls revoke_nosync() on another
CPU.

The revoker that does not claim the is_available swap returns
immediately, but the revoker that did may still be executing
drop_in_place() on the inner data. This can cause a use-after-free when
the other revoker's caller proceeds to drop adjacent resources that
drop_in_place() still references (e.g., Devres<DmaMappedSgt> racing with
SGTable freeing the backing sg_table and pages).

Fix this by adding a Completion. The release callback signals the
Completion after revoke() finishes, and Devres::drop() waits for it when
it loses the is_available swap. This ensures the wrapped object is fully
torn down before Devres::drop() returns.

Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/dri-devel/20260612202841.2577C1F000E9@smtp.kernel.org/
Fixes: 05aa6fb1c21d ("rust: scatterlist: Add abstraction for sg_table")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260628174451.2275679-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: dma: return zero for Coherent reads past EOF 2026-09-07T15:36:31+00:00 Younes Akhouayri git@younes.io 2026-07-30T16:34:38+00:00 a6756230ab95b38b239441bd4a82b6e3e0e0db9e commit 5391b147d9fd8d4736e28c629cda00fd37c2304a upstream. Coherent<T>::write_to_slice() calculates a zero-byte copy when the file offset is beyond the allocation, but still calls UserSliceWriter::write_dma(). The latter rejects offsets beyond the allocation even when the copy length is zero, so a debugfs read past EOF returns -ERANGE. Return before calling write_dma() when the offset is at or beyond the allocation, matching simple_read_from_buffer() EOF semantics. Fixes: 016818513936 ("rust: dma: implement BinaryWriter for Coherent<[u8]>") Cc: stable@vger.kernel.org Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/.E2.9C.94.20Possible.20past-EOF.20bug.20in.20Coherent.3CT.3E.3A.3Awrite_to_slice/near/611677095 Signed-off-by: Younes Akhouayri <git@younes.io> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Onur Özkan <work@onurozkan.dev> Link: https://patch.msgid.link/20260730-fix-dma-coherent-eof-v2-1-8aff21054afa@younes.io Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5391b147d9fd8d4736e28c629cda00fd37c2304a upstream.

Coherent<T>::write_to_slice() calculates a zero-byte copy when the file
offset is beyond the allocation, but still calls
UserSliceWriter::write_dma(). The latter rejects offsets beyond the
allocation even when the copy length is zero, so a debugfs read past EOF
returns -ERANGE.

Return before calling write_dma() when the offset is at or beyond the
allocation, matching simple_read_from_buffer() EOF semantics.

Fixes: 016818513936 ("rust: dma: implement BinaryWriter for Coherent<[u8]>")
Cc: stable@vger.kernel.org
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/.E2.9C.94.20Possible.20past-EOF.20bug.20in.20Coherent.3CT.3E.3A.3Awrite_to_slice/near/611677095
Signed-off-by: Younes Akhouayri <git@younes.io>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Link: https://patch.msgid.link/20260730-fix-dma-coherent-eof-v2-1-8aff21054afa@younes.io
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: bug: prevent dead_code warning from warn_on!'s flags constant 2026-09-07T15:36:31+00:00 FUJITA Tomonori fujita.tomonori@gmail.com 2026-08-01T02:48:41+00:00 0523fab5f6cfbad864527248aae5523f2d13b1b6 commit e66cfc29e0d06fec34c06bb40d4d281f595677b1 upstream. Fix the following dead_code warning on some configurations in an atomic development branch: warning: constant `WARN_ON_FLAGS` is never used --> linux/rust/kernel/bug.rs:126:19 | 126 | const WARN_ON_FLAGS: u32 = $crate::bug::bugflag_taint($crate::bindings::TAINT_WARN); | ^^^^^^^^^^^^^ | ::: linux/rust/kernel/sync/srcu.rs:106:12 | 106 | if crate::warn_on!( | ____________- 107 | | // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct` 108 | | // and `srcu_readers_active()` only checks the active reader count. 109 | | unsafe { bindings::srcu_readers_active(ptr) } 110 | | ) { | |_________- in this macro invocation | = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default = note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info) The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it to warn_flags!. On configurations where warn_flags! does not reference its flags argument (the LOONGARCH/ARM variant, which only calls WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left unused and triggers a dead_code warning. warn_flags! is the macro that accepts (and here discards) the flags argument, so make it responsible for the argument it drops. Also rename `_COND_STR` to `COND_STR` and consume `$file` for consistency. Fixes: dff64b072708 ("rust: Add warn_on macro") Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org [ Added newlines. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e66cfc29e0d06fec34c06bb40d4d281f595677b1 upstream.

Fix the following dead_code warning on some configurations in an
atomic development branch:

warning: constant `WARN_ON_FLAGS` is never used
   --> linux/rust/kernel/bug.rs:126:19
    |
126 |               const WARN_ON_FLAGS: u32 = $crate::bug::bugflag_taint($crate::bindings::TAINT_WARN);
    |                     ^^^^^^^^^^^^^
    |
   ::: linux/rust/kernel/sync/srcu.rs:106:12
    |
106 |           if crate::warn_on!(
    |  ____________-
107 | |             // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
108 | |             // and `srcu_readers_active()` only checks the active reader count.
109 | |             unsafe { bindings::srcu_readers_active(ptr) }
110 | |         ) {
    | |_________- in this macro invocation
    |
    = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
    = note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info)

The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it
to warn_flags!. On configurations where warn_flags! does not reference
its flags argument (the LOONGARCH/ARM variant, which only calls
WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left
unused and triggers a dead_code warning.

warn_flags! is the macro that accepts (and here discards) the flags
argument, so make it responsible for the argument it drops.

Also rename `_COND_STR` to `COND_STR` and consume `$file` for consistency.

Fixes: dff64b072708 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org
[ Added newlines. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: bug: fix warn_on macro build error on UML 2026-09-07T15:36:31+00:00 FUJITA Tomonori fujita.tomonori@gmail.com 2026-08-07T11:24:27+00:00 f391fef4122a9aa02878e5090e3b1d08f492feda commit 30a449e04a32033d8e4844fdb4938a0ebccfa37b upstream. Callers that go through `kernel::prelude` have `CStrExt` in scope, but code inside the `kernel` crate imports explicitly and may not. Using `warn_on!` from such a module fails to build on UML, which is the only configuration where `warn_flags!` needs a C string pointer rather than an inline asm bug entry: error[E0599]: no method named `as_char_ptr` found for reference `&ffi::CStr` in the current scope --> linux/rust/kernel/bug.rs:83:49 | 83 | $crate::c_str!(::core::file!()).as_char_ptr(), | ^^^^^^^^^^^ | ::: linux/rust/kernel/time.rs:427:9 | 427 | warn_on!(self.nanos < 0); | ------------------------ in this macro invocation | = help: items from traits can only be used if the trait is in scope = note: this error originates in the macro `$crate::warn_flags` which comes from the expansion of the macro `warn_on` (in Nightly builds, run with -Z mac) help: trait `CStrExt` which provides `as_char_ptr` is implemented but not in scope; perhaps you want to import it --> linux/rust/kernel/time.rs:27:1 | 27 + use crate::str::CStrExt; Call the method through its fully qualified path, which resolves without any import at the expansion site. Cc: stable@vger.kernel.org Fixes: dff64b072708 ("rust: Add warn_on macro") Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20260807112427.1039056-1-tomo@flapping.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 30a449e04a32033d8e4844fdb4938a0ebccfa37b upstream.

Callers that go through `kernel::prelude` have `CStrExt` in scope, but
code inside the `kernel` crate imports explicitly and may not. Using
`warn_on!` from such a module fails to build on UML, which is the only
configuration where `warn_flags!` needs a C string pointer rather than an
inline asm bug entry:

error[E0599]: no method named `as_char_ptr` found for reference `&ffi::CStr` in the current scope
   --> linux/rust/kernel/bug.rs:83:49
    |
 83 |                 $crate::c_str!(::core::file!()).as_char_ptr(),
    |                                                 ^^^^^^^^^^^
    |
   ::: linux/rust/kernel/time.rs:427:9
    |
427 |         warn_on!(self.nanos < 0);
    |         ------------------------ in this macro invocation
    |
    = help: items from traits can only be used if the trait is in scope
    = note: this error originates in the macro `$crate::warn_flags` which comes from the expansion of the macro `warn_on` (in Nightly builds, run with -Z mac)
help: trait `CStrExt` which provides `as_char_ptr` is implemented but not in scope; perhaps you want to import it
   --> linux/rust/kernel/time.rs:27:1
    |
 27 + use crate::str::CStrExt;

Call the method through its fully qualified path, which resolves
without any import at the expansion site.

Cc: stable@vger.kernel.org
Fixes: dff64b072708 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20260807112427.1039056-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: bug: skip arch-specific asm in `testlib` builds 2026-09-07T15:36:31+00:00 FUJITA Tomonori fujita.tomonori@gmail.com 2026-08-08T02:26:08+00:00 f49982cc4b9b6986c912e8d5fa406a19626cc085 commit 5d9668f3930609ead91f39b059ef4fe53db04942 upstream. Running `make rusttest` with `ARCH=` set to an architecture other than the host's fails, e.g. `ARCH=arm64` on an x86_64 host: error: invalid instruction mnemonic 'brk' --> rust/kernel/bug.rs:63:17 | 63 | / concat!( 64 | | "/* {size} */", 65 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_warn_asm.rs")), 66 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_reachable_asm.rs"))); | |_______________________________________________________________________________________________________^ | note: instantiated into assembly here --> <inline asm>:1:115 | 1 | /* 8 */.pushsection __bug_table,"aw"; .align 2; 14470: .long 14471f - .;.short 2305;.align 2; .popsection; 14471:brk 0x800 | ^^^ The reason is that `rusttest` builds the `kernel` crate as a host library: it passes the `CONFIG_*` cfgs of the configured architecture, but not `--target`, so code generation happens for the host. `warn_flags!` then selects the arch-specific inline asm arm based on `CONFIG_*`, and the host assembler rejects it. This does not happen with the current `master` because `warn_on!` has no user inside the `kernel` crate itself yet, but it will as soon as one is added. Reported-by: Miguel Ojeda <ojeda@kernel.org> Closes: https://lore.kernel.org/all/CANiq72n4=fz=JNKY0Jdm8BnLa=RmHB2B7s0bO47YTJ7hygqBZg@mail.gmail.com/ Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Cc: stable@vger.kernel.org Fixes: dff64b072708 ("rust: Add warn_on macro") Link: https://patch.msgid.link/20260808022608.1125174-1-tomo@flapping.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5d9668f3930609ead91f39b059ef4fe53db04942 upstream.

Running `make rusttest` with `ARCH=` set to an architecture other than
the host's fails, e.g. `ARCH=arm64` on an x86_64 host:

error: invalid instruction mnemonic 'brk'
  --> rust/kernel/bug.rs:63:17
   |
63 | /                 concat!(
64 | |                     "/* {size} */",
65 | |                     include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_warn_asm.rs")),
66 | |                     include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_reachable_asm.rs")));
   | |_______________________________________________________________________________________________________^
   |
note: instantiated into assembly here
  --> <inline asm>:1:115
   |
 1 |     /* 8 */.pushsection __bug_table,"aw"; .align 2; 14470: .long 14471f - .;.short 2305;.align 2; .popsection; 14471:brk 0x800
   |                                                                                                                      ^^^

The reason is that `rusttest` builds the `kernel` crate as a host
library: it passes the `CONFIG_*` cfgs of the configured architecture,
but not `--target`, so code generation happens for the
host. `warn_flags!` then selects the arch-specific inline asm arm
based on `CONFIG_*`, and the host assembler rejects it.

This does not happen with the current `master` because `warn_on!` has
no user inside the `kernel` crate itself yet, but it will as soon as
one is added.

Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/all/CANiq72n4=fz=JNKY0Jdm8BnLa=RmHB2B7s0bO47YTJ7hygqBZg@mail.gmail.com/
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: stable@vger.kernel.org
Fixes: dff64b072708 ("rust: Add warn_on macro")
Link: https://patch.msgid.link/20260808022608.1125174-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: fmt: fix {:p} printing stack addresses 2026-09-07T15:36:30+00:00 Ke Sun sunke@kylinos.cn 2026-08-10T06:35:42+00:00 c0eab781e1823590920fcfbde6d763b96fde3399 commit fb7d645176189d2b068d69861e230fa5aceb4922 upstream. The `impl_fmt_adapter_forward!` macro forwards `Pointer` for `Adapter<T>` by destructuring `self` into a local `t`, causing `{:p}` to print the address of that temporary stack variable rather than the actual pointer. Remove `Pointer` from the macro and provide a manual impl for `Adapter<&T>` that passes `self.0` directly. Signed-off-by: Ke Sun <sunke@kylinos.cn> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Link Mauve <linkmauve@linkmauve.fr> Cc: stable@vger.kernel.org Fixes: c5cf01ba8dfe ("rust: support formatting of foreign types") Link: https://patch.msgid.link/20260810-hashedptr-v15-1-eafd27d36476@kylinos.cn Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fb7d645176189d2b068d69861e230fa5aceb4922 upstream.

The `impl_fmt_adapter_forward!` macro forwards `Pointer` for
`Adapter<T>` by destructuring `self` into a local `t`, causing `{:p}`
to print the address of that temporary stack variable rather than the
actual pointer.

Remove `Pointer` from the macro and provide a manual impl for
`Adapter<&T>` that passes `self.0` directly.

Signed-off-by: Ke Sun <sunke@kylinos.cn>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Tested-by: Link Mauve <linkmauve@linkmauve.fr>
Cc: stable@vger.kernel.org
Fixes: c5cf01ba8dfe ("rust: support formatting of foreign types")
Link: https://patch.msgid.link/20260810-hashedptr-v15-1-eafd27d36476@kylinos.cn
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>