linux-stable.git/rust, branch v7.2.6

rust: uapi: replace direct asm-generic/ioctl.h include with linux/ioctl.h

2026-09-14T11:40:37+00:00

[ Upstream commit cdfcaa36ac93aa96df8310d7e57860f7600b2861 ]

rust/uapi/uapi_helper.h was directly including 
instead of the proper .

On powerpc,  pulls in  first, which
defines _IOC_SIZEBITS, _IOC_DIRBITS, _IOC_NONE, and _IOC_WRITE with the
arch-specific values, before falling through to .
By bypassing that chain and including  directly,
the arch-specific overrides never ran first, so when other headers in
the compilation later brought in the full arch-aware chain, Clang saw
those four macros being defined a second time and emitted:

clang diag: arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning: '_IOC_SIZEBITS' macro redefined [-Wmacro-redefined]
clang diag: arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning: '_IOC_DIRBITS' macro redefined [-Wmacro-redefined]
clang diag: arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning: '_IOC_NONE' macro redefined [-Wmacro-redefined]
clang diag: arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning: '_IOC_WRITE' macro redefined [-Wmacro-redefined]

Fix this by replacing the direct include of 
with , which is the correct arch-aware entry point
and already maintains the intended include order.

Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202608050618.9dekfjtF-lkp@intel.com/
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) 
Fixes: 4e1746656839 ("rust: uapi: Add UAPI crate")
Link: https://patch.msgid.link/20260811063345.685884-1-mkchauras@gmail.com
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: cpufreq: Fix temporary write in Registration::bios_limit_callback

2026-09-14T11:40:23+00:00

[ Upstream commit 19c76bdd3fc02475c73c8576f6f4a55ff07886f1 ]

In `Registration::bios_limit_callback`, the expression
`&mut (unsafe { *limit })` creates a reference to a temporary copy
of the value pointed to by `limit` on the stack.
Therefore, writes made by `T::bios_limit` go to this temporary
instead of the memory location pointed to by `limit`.

Additionally, `limit` may be uninitialized, such as when
`Registration::bios_limit_callback` is invoked by `show_bios_limit`
in drivers/cpufreq/cpufreq.c. Therefore creating a reference to
`limit` is unsound.

Fix this by changing the signature of `T::bios_limit` to return the limit
value.
`Registration::bios_limit_callback` can then update `limit` directly.

Fixes: c6af9a1191d042839e56abff69e8b0302d117988 ("rust: cpufreq: Extend abstractions for driver registration")
Reported-by: Dylan Zueck
Reported-by: Yuan Tan
Assisted-by: ChatGPT:gpt-5.4
Signed-off-by: Priya Bala Govindasamy
[ Viresh: Fix rustfmtcheck warning ]
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

rust: cpufreq: Add CPUFREQ_TABLE_END as last table entry in TableBuilder::to_table

2026-09-14T11:40:23+00:00

[ Upstream commit b5e4771f20a37fdf19eac0824bf062dffb4e291f ]

The `TableBuilder::to_table` function adds `Hertz(c_ulong::MAX).as_khz()`
as the last frequency entry in the frequency table.
But the C API expects the last entry to have frequency set to
`CPUFREQ_TABLE_END` which is `~1u` as per include/linux/cpufreq.h.

Fix this by setting the last frequency entry to `CPUFREQ_TABLE_END`
instead of `Hertz(c_ulong::MAX).as_khz()`.

Fixes: 2207856ff0bc8d953d6e89bda70b8978c2de8bab ("rust: cpufreq: Add initial abstractions for cpufreq framework")
Reported-by: Dylan Zueck
Reported-by: Yuan Tan
Assisted-by: ChatGPT:gpt-5.6-terra
Signed-off-by: Priya Bala Govindasamy
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled

2026-09-14T11:40:02+00:00

[ Upstream commit be809b60cbb61aab96179f44ac3670242ae72996 ]

When building with LLVM=1 for architectures like powerpc where
CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with:

  ld.lld: error: undefined symbol: dma_resv_reset_max_fences
  >>> referenced by helpers.c
  >>>               rust/helpers/helpers.o:(rust_helper_dma_resv_unlock)

The issue occurs because:
1. CONFIG_DEBUG_MUTEXES=y is enabled
2. CONFIG_DMA_SHARED_BUFFER is not enabled
3. dma_resv_reset_max_fences() is declared in the header when
   CONFIG_DEBUG_MUTEXES is set
4. But the function is only compiled in drivers/dma-buf/dma-resv.c,
   which is only built when CONFIG_DMA_SHARED_BUFFER is enabled
5. Rust helpers call dma_resv_unlock() which calls
   dma_resv_reset_max_fences(), causing an undefined symbol

Fix this by compiling `dma-resv.c` file only when CONFIG_DMA_SHARED_BUFFER
is enabled.

Fixes: 9b836641d3bf ("rust: helpers: Add bindings/wrappers for dma_resv_lock")
Reviewed-by: Christian König 
Reviewed-by: Gary Guo 
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260708082454.1254320-3-mkchauras@gmail.com
Signed-off-by: Sasha Levin

rust: device: make lifetime on `Core` and `CoreInternal` invariant

2026-09-14T11:39:40+00:00

[ Upstream commit f7acb19abcd867e5d2e1feb6197dcc65aa3b8e45 ]

Currently the lifetime on `Core` and `CoreInternal` is covariant. This
means that they can be coerced into shorter living lifetimes. On `probe`
function, signature has `&'bound Device>`; the type's wellformness
would imply `'a: 'bound` and thus the type can be coerced `&'bound
Device>`, defeating the purpose of having the lifetime bound
to prevent users of the `Core` type to escape the function.

Fix this by making the lifetime invariant, so the coercion is impossible.
The lifetime here only needs to be "branded" so it does not coerce or unify
with other lifetimes, so we do not need to ensure `'bound: 'a`.

This requires modifying `nova-core` which relies on this implied bound due
to pre-2024 capture rule. The "use" bound can be removed if built with
edition 2024.

Fixes: 24799831d631 ("rust: device: make Core and CoreInternal lifetime-parameterized")
Signed-off-by: Gary Guo 
Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org
[ Fixup the debugfs sample to use an explicit lifetime instead of
  Core<'_>. - Danilo ]
Signed-off-by: Danilo Krummrich 
Signed-off-by: Sasha Levin

rust: drm: gpuvm: require Send + Sync for the driver's associated data

2026-09-14T11:39:27+00:00

[ Upstream commit b59ec72fec247b90dc26f17c5b1ee9f1e0fe334c ]

DriverGpuVm permitted !Send/!Sync associated data on an abstraction whose
handles are shared and dropped across threads: obtain() runs from many
threads and the VA API performs deferred cross-thread drops. That is
unsound.

Require Send + Sync on the trait and its associated data so the GpuVm and
UniqueRefGpuVm handle impls need no per-impl bounds.

Fixes: 82b78182eacf ("rust: drm: add base GPUVM immediate mode abstraction")
Signed-off-by: Sami Tolvanen 
Link: https://patch.msgid.link/20260611-gpuvm-sync-send-v4-1-6c7f4ab2778a@google.com
Signed-off-by: Alice Ryhl 
Signed-off-by: Sasha Levin

rust: drm: gpuvm: update DriverGpuVm for DeviceContext

2026-09-14T11:39:03+00:00

[ Upstream commit 20003c1a1fd80ae1b1742ff54297b67f7f21b77f ]

Since the introduction of DeviceContext, there is no longer a single
driver object type to equate with the GPUVM object type.

Instead of threading DeviceContext through GPUVM, remove the strict
identity between DriverGpuVm::Object and drm::Driver::Object and
instead tighten the requirement that the DriverGpuVm::Object be an
allocatable GEM object associated with the same DRM driver.

Also, make GpuVm::new() generic over DeviceContext so it can accept a
drm::Device.

Fixes: 0023a1e8d01a ("rust/drm/gem: Use DeviceContext with GEM objects")
Signed-off-by: Deborah Brouwer 
Reviewed-by: Alice Ryhl 
Reviewed-by: Sami Tolvanen 
Link: https://patch.msgid.link/20260610-gpuvm_device_context_v1-v1-1-01a890b17448@collabora.com
Signed-off-by: Danilo Krummrich 
Signed-off-by: Sasha Levin

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

2026-09-11T09:51:10+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: num: reject Bounded::shr overshifts at build time

2026-09-07T15:37:23+00:00

[ 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 
Acked-by: Alexandre Courbot 
Reviewed-by: Gary Guo 
Reviewed-by: Danilo Krummrich 
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 
Signed-off-by: Sasha Levin

kbuild: rust: keep Rust objects out of Clang LTO with inline helpers

2026-09-07T15:36:32+00:00

commit 5febf432df1cfa5b25d99b54c32103fafbdd0eb9 upstream.

Under `CONFIG_LTO_CLANG` + `CONFIG_RUST_INLINE_HELPERS`, one may hit
`objtool` errors such as:

    vmlinux.o: error: objtool: _R..._3Gsp4boot+0xd6a:
    can't find jump dest instruction at .text._R..._3Gsp4boot+0x1dfd

The reason is that in such builds, the Clang invocation that compiles
the combined Rust plus helpers bitcode emits LLVM bitcode (again) --
the final code generation happens in the linker's LTO step, which the
`-mllvm` trap options passed to Clang do not reach.

This, in turn, means that unreachable traps are missing, and the
impossible paths do not merely fallthrough to the next symbol, but past
the end of their own section, since LTO builds place each function in
its own section.

Thus filter `CC_FLAGS_LTO` out of the Clang invocation, so that it always
emits machine code directly, with the traps in place.

Assisted-by: LLM
Cc: Gary Guo 
Cc: Boqun Feng 
Cc: Alice Ryhl 
Cc: Matthew Maurer 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: stable@vger.kernel.org
Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust")
Acked-by: Gary Guo 
Link: https://patch.msgid.link/20260816133233.197500-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman