linux-stable.git/rust/kernel, branch v6.18.33

rust: sync: atomic: Remove bound `T: Sync` for `Atomic::from_ptr()`

2026-05-23T11:06:25+00:00

[ Upstream commit 4a5dc632e0b603ec1cbbf87b78de86b4b6359cff ]

Originally, `Atomic::from_ptr()` requires `T` being a `Sync` because I
thought having the ability to do `from_ptr()` meant multiplle
`&Atomic`s shared by different threads, which was identical (or
similar) to multiple `&T`s shared by different threads. Hence `T` was
required to be `Sync`. However this is not true, since `&Atomic` is
not the same at `&T`. Moreover, having this bound makes `Atomic::<*mut
T>::from_ptr()` impossible, which is definitely not intended. Therefore
remove the `T: Sync` bound.

[boqun: Fix title typo spotted by Alice & Gary]

Fixes: 29c32c405e53 ("rust: sync: atomic: Add generic atomics")
Signed-off-by: Boqun Feng 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Alice Ryhl 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260120115207.55318-2-boqun.feng@gmail.com
Link: https://patch.msgid.link/20260303201701.12204-2-boqun@kernel.org
Signed-off-by: Sasha Levin

cpufreq: Pass the policy to cpufreq_driver->adjust_perf()

2026-05-23T11:06:24+00:00

[ Upstream commit c03791085adcd61fa9b766ab303c7d0941d7378d ]

cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent
writer(s), however amd-pstate depends on fetching the cpudata via the
policy's driver data which necessitates grabbing the reference.

Since schedutil governor can call "cpufreq_driver->update_perf()"
during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled,
fetching the policy object using the cpufreq_cpu_get() helper in the
scheduler fast-path leads to "BUG: scheduling while atomic" on
PREEMPT_RT [1].

Pass the cached cpufreq policy object in sg_policy to the update_perf()
instead of just the CPU. The CPU can be inferred using "policy->cpu".

The lifetime of cpufreq_policy object outlasts that of the governor and
the cpufreq driver (allocated when the CPU is onlined and only reclaimed
when the CPU is offlined / the CPU device is removed) which makes it
safe to be referenced throughout the governor's lifetime.

Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1]

Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State")
Reported-by: Bert Karwatzki 
Acked-by: Viresh Kumar 
Signed-off-by: K Prateek Nayak 
Acked-by: Gary Guo  # Rust
Reviewed-by: Gautham R. Shenoy 
Reviewed-by: Zhongqiu Han 
Link: https://lore.kernel.org/r/20260316081849.19368-3-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello (AMD) 
Signed-off-by: Sasha Levin

rust: drm: gem: clean up GEM state in init failure case

2026-05-14T13:30:14+00:00

commit 2e42a17b8f6bc3c0cd69d7556b588011d3ec2394 upstream.

Currently, if `drm_gem_object_init` fails, the object is freed without
any cleanup. Perform the cleanup in that case.

Cc: stable@vger.kernel.org
Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction")
Signed-off-by: Eliot Courtney 
Reviewed-by: Alice Ryhl 
Reviewed-by: Onur Özkan 
Link: https://patch.msgid.link/20260423-fix-gem-1-v1-1-e12e35f7bba9@nvidia.com
[ Move safety comment closer to unsafe block to avoid a clippy warning.
  - Danilo ]
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: dma: remove DMA_ATTR_NO_KERNEL_MAPPING from public attrs

2026-05-07T04:11:33+00:00

commit 18fb5f1f0289b8217c0c43d54d12bccc201dd640 upstream.

When DMA_ATTR_NO_KERNEL_MAPPING is passed to dma_alloc_attrs(), the
returned CPU address is not a pointer to the allocated memory but an
opaque handle (e.g. struct page *).

Coherent (or CoherentAllocation respectively) stores this value as
NonNull and exposes methods that dereference it and even modify its
contents.

Remove the flag from the public attrs module such that drivers cannot
pass it to Coherent (or CoherentAllocation respectively) in the
first place.

Instead DMA_ATTR_NO_KERNEL_MAPPING can be supported with an additional
opaque type (e.g. CoherentHandle) which does not provide access to the
allocated memory.

Cc: stable@vger.kernel.org
Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction")
Signed-off-by: Danilo Krummrich 
Reviewed-by: Alice Ryhl 
Reviewed-by: Alexandre Courbot 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260321172749.592387-1-dakr@kernel.org
Signed-off-by: Alexandre Courbot 
Signed-off-by: Greg Kroah-Hartman

rust: regulator: do not assume that regulator_get() returns non-null

2026-04-02T11:23:14+00:00

[ Upstream commit 8121353a4bf8e38afee26299419a78ec108e14a6 ]

The Rust `Regulator` abstraction uses `NonNull` to wrap the underlying
`struct regulator` pointer. When `CONFIG_REGULATOR` is disabled, the C
stub for `regulator_get` returns `NULL`. `from_err_ptr` does not treat
`NULL` as an error, so it was passed to `NonNull::new_unchecked`,
causing undefined behavior.

Fix this by using a raw pointer `*mut bindings::regulator` instead of
`NonNull`. This allows `inner` to be `NULL` when `CONFIG_REGULATOR` is
disabled, and leverages the C stubs which are designed to handle `NULL`
or are no-ops.

Fixes: 9b614ceada7c ("rust: regulator: add a bare minimum regulator abstraction")
Reported-by: Miguel Ojeda 
Closes: https://lore.kernel.org/r/20260322193830.89324-1-ojeda@kernel.org
Signed-off-by: Alice Ryhl 
Reviewed-by: Daniel Almeida 
Link: https://patch.msgid.link/20260324-regulator-fix-v1-1-a5244afa3c15@google.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

rust: str: make NullTerminatedFormatter public

2026-03-19T15:08:24+00:00

commit 3ac88a9948792b092a4b11323e2abd1ecbe0cc68 upstream.

If `CONFIG_BLOCK` is disabled, the following warnings are displayed
during build:

  warning: struct `NullTerminatedFormatter` is never constructed
    --> ../rust/kernel/str.rs:667:19
      |
  667 | pub(crate) struct NullTerminatedFormatter<'a> {
      |                   ^^^^^^^^^^^^^^^^^^^^^^^
      |
      = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default

  warning: associated function `new` is never used
    --> ../rust/kernel/str.rs:673:19
      |
  671 | impl<'a> NullTerminatedFormatter<'a> {
      | ------------------------------------ associated function in this implementation
  672 |     /// Create a new [`Self`] instance.
  673 |     pub(crate) fn new(buffer: &'a mut [u8]) -> Option> {

Fix them by making `NullTerminatedFormatter` public, as it could be
useful for drivers anyway.

Fixes: cdde7a1951ff ("rust: str: introduce `NullTerminatedFormatter`")
Signed-off-by: Alexandre Courbot 
Reviewed-by: Alice Ryhl 
Reviewed-by: Andreas Hindborg 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260224-nullterminatedformatter-v1-1-5bef7b9b3d4c@nvidia.com
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: kunit: fix warning when !CONFIG_PRINTK

2026-03-12T11:09:52+00:00

[ Upstream commit 7dd34dfc8dfa92a7244242098110388367996ac3 ]

If `CONFIG_PRINTK` is not set, then the following warnings are issued
during build:

  warning: unused variable: `args`
    --> ../rust/kernel/kunit.rs:16:12
    |
  16 | pub fn err(args: fmt::Arguments<'_>) {
    |            ^^^^ help: if this is intentional, prefix it with an underscore: `_args`
    |
    = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

  warning: unused variable: `args`
    --> ../rust/kernel/kunit.rs:32:13
    |
  32 | pub fn info(args: fmt::Arguments<'_>) {
    |             ^^^^ help: if this is intentional, prefix it with an underscore: `_args`

Fix this by adding a no-op assignment using `args` when `CONFIG_PRINTK`
is not set.

Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones")
Signed-off-by: Alexandre Courbot 
Reviewed-by: Alice Ryhl 
Reviewed-by: David Gow 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

rust: list: Add unsafe blocks for container_of and safety comments

2026-03-04T12:21:35+00:00

[ Upstream commit 97b281d7edb2ae662365be2809cd728470119720 ]

impl_list_item_mod.rs calls container_of! without unsafe blocks at a
couple of places. Since container_of! is unsafe, the blocks are strictly
necessary.

The problem was so far not visible because the "unsafe-op-in-unsafe-fn"
check is a lint rather than a hard compiler error, and Rust suppresses
lints triggered inside of a macro from another crate.

Thus, the error becomes only visible once someone from within the kernel
crate tries to use linked lists:

    error[E0133]: call to unsafe function `core::ptr::mut_ptr::::byte_sub`
    is unsafe and requires unsafe block
       --> rust/kernel/lib.rs:252:29
        |
    252 |           let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>();
        |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
        |
       ::: rust/kernel/drm/jq.rs:98:1
        |
    98  | / impl_list_item! {
    99  | |     impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
    100 | | }
        | |_- in this macro invocation
        |
    note: an unsafe function restricts its caller, but its body is safe by default
       --> rust/kernel/list/impl_list_item_mod.rs:216:13
        |
    216 |               unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
        |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        |
       ::: rust/kernel/drm/jq.rs:98:1
        |
    98  | / impl_list_item! {
    99  | |     impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
    100 | | }
        | |_- in this macro invocation
        = note: requested on the command line with `-D unsafe-op-in-unsafe-fn`
        = note: this error originates in the macro `$crate::container_of` which comes
        from the expansion of the macro `impl_list_item`

Therefore, add unsafe blocks to container_of! calls to fix the issue.

[ As discussed, let's fix the build for those that want to use the
  macro within the `kernel` crate now and we can discuss the proper
  safety comments afterwards. Thus I removed the ones from the patch.

  However, we cannot just avoid the comments with `CLIPPY=1`, so I
  provided placeholders for now, like we did in the past. They were
  also needed for an `unsafe impl`.

  While I am not happy about it, it isn't worse than the current
  status (the comments were meant to be there), and at least this
  shows what is missing -- our pre-existing "good first issue" [1]
  may motivate new contributors to complete them properly.

  Finally, I moved one of the existing safety comments one line down
  so that Clippy could locate it.

  Link: https://github.com/Rust-for-Linux/linux/issues/351 [1]

    - Miguel ]

Cc: stable@vger.kernel.org
Fixes: c77f85b347dd ("rust: list: remove OFFSET constants")
Suggested-by: Alice Ryhl 
Signed-off-by: Philipp Stanner 
Reviewed-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20260216131613.45344-3-phasta@kernel.org
[ Fixed formatting. Reworded to fix the lint suppression
  explanation. Indent build error. - Miguel ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: irq: add `'static` bounds to irq callbacks

2026-03-04T12:21:33+00:00

[ Upstream commit 621609f1e5ca43a75edd497dd1c28bd84aa66433 ]

These callback functions take a generic `T` that is used in the body as
the generic argument in `Registration` and `ThreadedRegistration`. Those
types require `T: 'static`, but due to a compiler bug this requirement
isn't propagated to the function. Thus add the bound. This was caught in
the upstream Rust CI [1].

[ The three errors looked similar and will start appearing with Rust
  1.95.0 (expected 2026-04-16). The first one was:

      error[E0310]: the parameter type `T` may not live long enough
      Error:    --> rust/kernel/irq/request.rs:266:43
          |
      266 |     let registration = unsafe { &*(ptr as *const Registration) };
          |                                           ^^^^^^^^^^^^^^^^^^^^^^
          |                                           |
          |                                           the parameter type `T` must be valid for the static lifetime...
          |                                           ...so that the type `T` will meet its required lifetime bounds
          |
      help: consider adding an explicit lifetime bound
          |
      264 | unsafe extern "C" fn handle_irq_callback(_irq: i32, ptr: *mut c_void) -> c_uint {
          |                                                     +++++++++

    - Miguel ]

Link: https://github.com/rust-lang/rust/pull/149389 [1]
Signed-off-by: Benno Lossin 
Cc: stable@vger.kernel.org
Fixes: 29e16fcd67ee ("rust: irq: add &Device argument to irq callbacks")
Reviewed-by: Gary Guo 
Reviewed-by: Daniel Almeida 
Acked-by: Danilo Krummrich 
Link: https://lore.kernel.org/rust-for-linux/20260217222425.8755-1-cole@unwrap.rs/
Link: https://patch.msgid.link/20260214092740.3201946-1-lossin@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust/drm: Fix Registration::{new,new_foreign_owned}() docs

2026-03-04T12:21:15+00:00

[ Upstream commit 638eeda8abaa3e6afe6bd5758ef8045a7f33b9a0 ]

Looks like we've actually had a malformed rustdoc reference in the rustdocs
for Registration::new_foreign_owned() for a while that, when fixed, still
couldn't resolve properly because it refers to a private item.

This is probably leftover from when Registration::new() was public, so drop
the documentation from that function and fixup the documentation for
Registration::new_foreign_owned().

Signed-off-by: Lyude Paul 
Acked-by: Danilo Krummrich 
Fixes: 0600032c54b7 ("rust: drm: add DRM driver registration")
Cc:  # v6.16+
Link: https://patch.msgid.link/20260122221037.3462081-1-lyude@redhat.com
Signed-off-by: Sasha Levin