linux-stable.git/rust, branch v6.18.51

rust: bug: prevent dead_code warning from warn_on!'s flags constant

2026-09-11T09:49:36+00:00

[ Upstream commit e66cfc29e0d06fec34c06bb40d4d281f595677b1 ]

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 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org
[ Added newlines. - Miguel ]
Signed-off-by: Miguel Ojeda 
[ adapted unreachable flag consumption to the older one-argument warn_flags! interface. ]
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rust: drm: ioctl: fix unbounded lifetimes in ioctl handler arguments

2026-09-11T09:49:23+00:00

commit 68b151bc6145dea3db5598ebaf4b776cd205e395 upstream.

References to dev, data, and file in the declare_drm_ioctls! macro are
created via unsafe pointer dereferences, producing unbounded lifetimes.
If an ioctl handler explicitly annotates its parameters with 'static,
the compiler accepts this, allowing the handler to stash references that
outlive the ioctl call.

Fix this by adding a higher-ranked function pointer coercion that
enforces the handler accepts universally quantified lifetimes:

  let _: for<'a> fn(&'a _, &'a mut _, &'a _) -> _ = $func;

Since the handler must be coercible to a function pointer accepting any
lifetime 'a, it can no longer demand 'static on any parameter.

Cc: stable@vger.kernel.org
Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260620011346.A47D01F000E9@smtp.kernel.org/
Suggested-by: Gary Guo 
Reviewed-by: Alexandre Courbot 
Reviewed-by: Lyude Paul 
Tested-by: Deborah Brouwer 
Link: https://patch.msgid.link/20260628145406.2107056-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: kernel: list: fix incorrect pop_back example comment

2026-09-07T15:22:21+00:00

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 
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 
Signed-off-by: Greg Kroah-Hartman

rust: bug: skip arch-specific asm in `testlib` builds

2026-09-07T15:22:21+00:00

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
  --> :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 
Closes: https://lore.kernel.org/all/CANiq72n4=fz=JNKY0Jdm8BnLa=RmHB2B7s0bO47YTJ7hygqBZg@mail.gmail.com/
Signed-off-by: FUJITA Tomonori 
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 
Signed-off-by: Greg Kroah-Hartman

rust: time: fix as_micros_ceil() rounding near i64::MAX

2026-09-07T15:22:20+00:00

commit ec90dfcf05f02206c280bb59af660bbb3ae177d0 upstream.

The ceiling adjustment used saturating_add(NSEC_PER_USEC - 1) before
dividing. Once the nanosecond value gets within NSEC_PER_USEC - 1 of
i64::MAX the addition saturates to i64::MAX, which drops the ceiling
bias and can yield a result one microsecond too small.

Fixes: fae0cdc12340 ("rust: time: Introduce Delta type")
Reported-by: Miguel Ojeda 
Closes: https://lore.kernel.org/rust-for-linux/CANiq72mtS0ABA2JnT5tpz6J9c_mnxY+vyPvghV_ukngWvN8F2w@mail.gmail.com/
Signed-off-by: FUJITA Tomonori 
Acked-by: Andreas Hindborg 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260807130531.1056209-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: device: avoid trailing ; in printing macros

2026-08-03T09:22:13+00:00

commit a19bda861b3a79e25417462539df8b0d77c6b322 upstream.

These macros are used like expressions, so they should not emit a
semicolon. This is being turned into a hard error in a future release of
Rust.

    error: trailing semicolon in macro used in expression position
      --> drivers/gpu/nova-core/firmware/fsp.rs:79:34
       |
    79 |                 .inspect_err(|_| dev_err!(dev, "FMC firmware missing '{}' section\n", name))
       |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       |
       = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
       = note: for more information, see issue #79813 
       = note: this error originates in the macro `dev_err` (in Nightly builds, run with -Z macro-backtrace for more info)

[ I was doubly surprised since upstream made it a deny-by-default lint
  a year ago for Rust 1.91.0, and yet we didn't see it; plus I hadn't
  seen this in my CI even yesterday.

  It turns out this just landed into today's nightly (nightly-2026-07-16,
  using upstream commit d0babd8b6):

    Link: https://github.com/rust-lang/rust/pull/159222

  which says:

    "The `semicolon_in_expressions_from_macros` lint previously
     suppressed warnings about non-local macros. This masks
     a lint that will subsequently become a hard error."

  So that explains it. And this is the PR that will make it a hard error
  at some point in the future:

    Link: https://github.com/rust-lang/rust/pull/159218

  Thus starting with Rust 1.99.0 (expected 2026-10-01), we will be
  seeing the deny-by-default lint above, so clean it up already.

    - Miguel ]

Cc: stable@vger.kernel.org # Needed in 6.18.y and later.
Link: https://github.com/rust-lang/rust/issues/79813
Signed-off-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Acked-by: Danilo Krummrich 
Link: https://github.com/rust-lang/rust/pull/159218
Link: https://github.com/rust-lang/rust/pull/159222
Link: https://patch.msgid.link/20260716-device-trail-semicolon-v1-1-f48e9dcfae15@google.com
[ Fixed typo. ]
Signed-off-by: Miguel Ojeda 
[ Resolved conflict on `dev_printk` by not performing a similar cleanup
  since it is not strictly needed. - Miguel ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >= 1.98

2026-08-03T09:22:13+00:00

commit 608045a91d9176d66b2114d0006bc8b57dff2ca9 upstream.

Starting with Rust 1.98.0 (expected 2026-08-20), Rust is introducing a
couple new lints, `invalid_runtime_symbol_definitions` (deny-by-default)
and `suspicious_runtime_symbol_definitions` (warn-by-default), which check
the signature of items whose symbol name is a runtime symbol expected by
`core`.

Our build hits the second one, i.e. the warning:

    error: suspicious definition of the runtime `strlen` symbol used by the standard library
         --> rust/bindings/bindings_generated.rs:20018:5
          |
    20018 |     pub fn strlen(s: *const ffi::c_char) -> usize;
          |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          |
          = note: expected `unsafe extern "C" fn(*const i8) -> usize`
                  found    `unsafe extern "C" fn(*const u8) -> usize`
          = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]`
          = help: allow this lint if the signature is compatible
          = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings`
          = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]`

    error: suspicious definition of the runtime `strlen` symbol used by the standard library
         --> rust/uapi/uapi_generated.rs:14236:5
          |
    14236 |     pub fn strlen(s: *const ffi::c_char) -> usize;
          |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          |
          = note: expected `unsafe extern "C" fn(*const i8) -> usize`
                  found    `unsafe extern "C" fn(*const u8) -> usize`
          = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]`
          = help: allow this lint if the signature is compatible
          = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings`
          = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]`

Thus `allow` the lint in `bindings` and `uapi`.

A more targeted alternative to avoid `allow`ing it would be to pass
`--blocklist-function strlen` to `bindgen`, but we would perhaps need
to adjust if other C headers end up adding more (or Rust checking more).
Since it is just the less critical one that we hit, and since eventually
this should be properly fixed by getting upstream Rust to provide a flag
like GCC/Clang's `-funsigned-char` [2][3], just `allow` it for now.

Cc: Urgau 
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/155521 [1]
Link: https://github.com/rust-lang/rust/issues/138446 [2]
Link: https://github.com/Rust-for-Linux/linux/issues/355 [3]
Reviewed-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Tamir Duberstein 
Link: https://patch.msgid.link/20260615143225.471756-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: time: fix as_micros_ceil() to round correctly for negative Delta

2026-08-03T09:21:58+00:00

commit 880c43b185ca52239e75bc546cc4f4d9154d0fed upstream.

The ceiling-division idiom `(n + d - 1) / d` only produces the
correct result when `n` is non-negative.

For example, if n = -1000 (exactly -1us), the old code computed (-1000
+ 999) / 1000 == 0 instead of -1.

For negative n, truncating division already rounds towards positive
infinity, so no bias is needed in that case.

Fixes: fae0cdc12340 ("rust: time: Introduce Delta type")
Signed-off-by: FUJITA Tomonori 
Acked-by: Andreas Hindborg 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260713225235.3243480-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: alloc: fix assert in `Vec::reserve` doc test

2026-07-24T14:16:16+00:00

[ Upstream commit 75619f2df7a5da6ffb61eedc2a73fdf70c65471c ]

The assert in the doctest used `>= 10`, which only checks that the
capacity can hold `additional` elements, ignoring the existing length
of `v`. The correct check should ensure there is room for `additional`
*extra* elements on top of what is already in the vector.

Fix the assert to use `>= v.len() + 10` so the example accurately
reflects the actual semantics of the function.

Reported-by: Miguel Ojeda 
Closes: https://lore.kernel.org/rust-for-linux/CANiq72nkXWhjK9iFRrhGtkMZGsvNE_zVsu4JnxaFRfxWL7RRdg@mail.gmail.com/
Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type")
Signed-off-by: Hsiu Che Yu 
Reviewed-by: Alice Ryhl 
Reviewed-by: Alexandre Courbot 
Link: https://patch.msgid.link/20260427-doctest-kvec-reserve-v1-1-0623abcd9c2e@gmail.com
Signed-off-by: Danilo Krummrich 
Signed-off-by: Sasha Levin

rust: alloc: fix `Vec::extend_with` SAFETY comment

2026-07-24T14:15:48+00:00

[ Upstream commit f497aae6ded43f91b1dbf29a35d7062823635640 ]

Fix an incorrect operator in the SAFETY comment, changing `<` to `<=`,
since `Vec::reserve` guarantees capacity for exactly n additional elements,
so the equal case should be included.

Signed-off-by: Hsiu Che Yu 
Reviewed-by: Alexandre Courbot 
Fixes: 2aac4cd7dae3d ("rust: alloc: implement kernel `Vec` type")
Link: https://patch.msgid.link/18fc8eee2f057a6bfbcadae156d1d0b7c40d0077.1777111268.git.yu.whisper.personal@gmail.com
Signed-off-by: Danilo Krummrich 
Signed-off-by: Sasha Levin