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

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

2026-05-23T11:08:29+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:08:28+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: pin-init: fix incorrect accessor reference lifetime

2026-05-14T13:31:20+00:00

commit 68bf102226cf2199dc609b67c1e847cad4de4b57 upstream

When a field has been initialized, `init!`/`pin_init!` create a reference
or pinned reference to the field so it can be accessed later during the
initialization of other fields. However, the reference it created is
incorrectly `&'static` rather than just the scope of the initializer.

This means that you can do

    init!(Foo {
        a: 1,
        _: {
            let b: &'static u32 = a;
        }
    })

which is unsound.

This is caused by `&mut (*#slot).#ident`, which actually allows arbitrary
lifetime, so this is effectively `'static`. Somewhat ironically, the safety
justification of creating the accessor is.. "SAFETY: TODO".

Fix it by adding `let_binding` method on `DropGuard` to shorten lifetime.
This results exactly what we want for these accessors. The safety and
invariant comments of `DropGuard` have been reworked; instead of reasoning
about what caller can do with the guard, express it in a way that the
ownership is transferred to the guard and `forget` takes it back, so the
unsafe operations within the `DropGuard` can be more easily justified.

Fixes: db96c5103ae6 ("add references to previously initialized fields")
Signed-off-by: Gary Guo 
Signed-off-by: Greg Kroah-Hartman

rust: pin-init: internal: move alignment check to `make_field_check`

2026-05-14T13:31:06+00:00

commit 83ac2870310b694775ab7e8f0244fdd94fc21926 upstream.

Instead of having the reference creation serving dual-purpose as both for
let bindings and alignment check, detangle them so that the alignment check
is done explicitly in `make_field_check`. This is more robust against
refactors that may change the way let bindings are created.

Cc: stable@vger.kernel.org
Reviewed-by: Alice Ryhl 
Signed-off-by: Gary Guo 
Link: https://patch.msgid.link/20260427-pin-init-fix-v3-1-496a699674dd@garyguo.net
[ Reworded for typo. - Miguel ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

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

2026-05-14T13:31:06+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:13:43+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-03-24T13:08:21+00:00

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

Merge tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux

2026-03-14T19:35:16+00:00

Pull Rust fixes from Miguel Ojeda:
 "Toolchain and infrastructure:

   - Remap paths to avoid absolute ones starting with the upcoming Rust
     1.95.0 release. This improves build reproducibility, avoids leaking
     the exact path and avoids having the same path appear in two forms

     The approach here avoids remapping debug information as well, in
     order to avoid breaking tools that used the paths to access source
     files, which was the previous attempt that needed to be reverted

   - Allow 'unused_features' lint for the upcoming Rust 1.96.0 release.
     While well-intentioned, we do not benefit much from the new lint

   - Emit dependency information into '$(depfile)' directly to avoid a
     temporary '.d' file (it was an old approach)

  'kernel' crate:

   - 'str' module: fix warning under '!CONFIG_BLOCK' by making
     'NullTerminatedFormatter' public

   - 'cpufreq' module: suppress false positive Clippy warning

  'pin-init' crate:

   - Remove '#[disable_initialized_field_access]' attribute which was
     unsound. This means removing the support for structs with unaligned
     fields (through the 'repr(packed)' attribute), for now

     And document the load-bearing fact of field accessors (i.e. that
     they are required for soundness)

   - Replace shadowed return token by 'unsafe'-to-create token in order
     to remain sound in the face of the likely upcoming Type Alias Impl
     Trait (TAIT) and the next trait solver in upstream Rust"

* tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
  rust: kbuild: allow `unused_features`
  rust: cpufreq: suppress clippy::double_parens in Policy doctest
  rust: pin-init: replace shadowed return token by `unsafe`-to-create token
  rust: pin-init: internal: init: document load-bearing fact of field accessors
  rust: pin-init: internal: init: remove `#[disable_initialized_field_access]`
  rust: build: remap path to avoid absolute path
  rust: kbuild: emit dep-info into $(depfile) directly
  rust: str: make NullTerminatedFormatter public

Merge tag 'drm-rust-fixes-2026-03-12' of https://gitlab.freedesktop.org/drm/rust/kernel into drm-fixes

2026-03-13T00:40:17+00:00

Core Changes:

- Fix safety issue in dma_read! and dma_write!.

Driver Changes (Nova Core):

- Fix UB in DmaGspMem pointer accessors.
- Fix stack overflow in GSP memory allocation.

Signed-off-by: Dave Airlie 

From: Alice Ryhl 
Link: https://patch.msgid.link/abNBSol3CLRCqlkZ@google.com

rust: cpufreq: suppress clippy::double_parens in Policy doctest

2026-03-12T10:01:23+00:00

The kernel fmt! proc macro wraps each format argument as &(arg). Passing a
tuple such as (a, b) produces &((a, b)) after expansion. Clippy flags that
as double_parens, but it is a false positive fixed in Clippy 1.92 [1] [2].

Suppress the warning on the affected doctest function with a reason
attribute so it can be removed once the minimum toolchain moves past 1.92.

[ We may end up deciding to support per-version Clippy lints, in which
  case we will need [3].

  In the future, if [4] gets fixed, we may be able to use
  `Delimiter::None` as Gary suggested in [5].

  Link: https://lore.kernel.org/rust-for-linux/20260307170929.153892-1-ojeda@kernel.org/ [3]
  Link: https://github.com/rust-lang/rust/issues/67062 [4]
  Link: https://lore.kernel.org/rust-for-linux/DGUA5GY2DGYN.3PG0FKLG7GFN1@garyguo.net/ [5]

    - Miguel ]

Link: https://github.com/rust-lang/rust-clippy/issues/15852 [1]
Link: https://github.com/rust-lang/rust-clippy/pull/15939 [2]
Suggested-by: Gary Guo 
Signed-off-by: John Hubbard 
Acked-by: Viresh Kumar 
Link: https://patch.msgid.link/20260312041934.362840-2-jhubbard@nvidia.com
[ Reworded to replace GitHub-like short link with full URLs in Link tags.
  Reworded reason string to match the style of a couple others we have
  elsewhere. - Miguel ]
Signed-off-by: Miguel Ojeda