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

rust: maple_tree: rcu_read_lock() in destructor to silence lockdep

2026-01-08T09:17:11+00:00

commit 6558749ef3405c143711cbdc67ec88cbc1582d91 upstream.

When running the Rust maple tree kunit tests with lockdep, you may trigger
a warning that looks like this:

	lib/maple_tree.c:780 suspicious rcu_dereference_check() usage!

	other info that might help us debug this:

	rcu_scheduler_active = 2, debug_locks = 1
	no locks held by kunit_try_catch/344.

	stack backtrace:
	CPU: 3 UID: 0 PID: 344 Comm: kunit_try_catch Tainted: G                 N  6.19.0-rc1+ #2 NONE
	Tainted: [N]=TEST
	Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
	Call Trace:
	 
	 dump_stack_lvl+0x71/0x90
	 lockdep_rcu_suspicious+0x150/0x190
	 mas_start+0x104/0x150
	 mas_find+0x179/0x240
	 _RINvNtCs5QSdWC790r4_4core3ptr13drop_in_placeINtNtCs1cdwasc6FUb_6kernel10maple_tree9MapleTreeINtNtNtBL_5alloc4kbox3BoxlNtNtB1x_9allocator7KmallocEEECsgxAQYCfdR72_25doctests_kernel_generated+0xaf/0x130
	 rust_doctest_kernel_maple_tree_rs_0+0x600/0x6b0
	 ? lock_release+0xeb/0x2a0
	 ? kunit_try_catch_run+0x210/0x210
	 kunit_try_run_case+0x74/0x160
	 ? kunit_try_catch_run+0x210/0x210
	 kunit_generic_run_threadfn_adapter+0x12/0x30
	 kthread+0x21c/0x230
	 ? __do_trace_sched_kthread_stop_ret+0x40/0x40
	 ret_from_fork+0x16c/0x270
	 ? __do_trace_sched_kthread_stop_ret+0x40/0x40
	 ret_from_fork_asm+0x11/0x20
	 

This is because the destructor of maple tree calls mas_find() without
taking rcu_read_lock() or the spinlock.  Doing that is actually ok in this
case since the destructor has exclusive access to the entire maple tree,
but it triggers a lockdep warning.  To fix that, take the rcu read lock.

In the future, it's possible that memory reclaim could gain a feature
where it reallocates entries in maple trees even if no user-code is
touching it.  If that feature is added, then this use of rcu read lock
would become load-bearing, so I did not make it conditional on lockdep.

We have to repeatedly take and release rcu because the destructor of T
might perform operations that sleep.

Link: https://lkml.kernel.org/r/20251217-maple-drop-rcu-v1-1-702af063573f@google.com
Fixes: da939ef4c494 ("rust: maple_tree: add MapleTree")
Signed-off-by: Alice Ryhl 
Reported-by: Andreas Hindborg 
Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/564215108
Reviewed-by: Gary Guo 
Reviewed-by: Daniel Almeida 
Cc: Andrew Ballance 
Cc: Björn Roy Baron 
Cc: Boqun Feng 
Cc: Danilo Krummrich 
Cc: Liam Howlett 
Cc: Matthew Wilcox (Oracle) 
Cc: Miguel Ojeda 
Cc: Trevor Gross 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

rust: io: add typedef for phys_addr_t

2026-01-02T11:57:05+00:00

commit dd6ff5cf56fb183fce605ca6a5bfce228cd8888b upstream.

The C typedef phys_addr_t is missing an analogue in Rust, meaning that
we end up using bindings::phys_addr_t or ResourceSize as a replacement
in various places throughout the kernel. Fix that by introducing a new
typedef on the Rust side. Place it next to the existing ResourceSize
typedef since they're quite related to each other.

Cc: stable@vger.kernel.org # for v6.18 [1]
Signed-off-by: Alice Ryhl 
Link: https://patch.msgid.link/20251112-resource-phys-typedefs-v2-4-538307384f82@google.com
Link: https://lore.kernel.org/all/20251112-resource-phys-typedefs-v2-0-538307384f82@google.com/ [1]
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: io: move ResourceSize to top-level io module

2026-01-02T11:57:05+00:00

commit dfd67993044f507ba8fd6ee9956f923ba4b7e851 upstream.

Resource sizes are a general concept for dealing with physical
addresses, and not specific to the Resource type, which is just one way
to access physical addresses. Thus, move the typedef to the io module.

Still keep a re-export under resource. This avoids this commit from
being a flag-day, but I also think it's a useful re-export in general so
that you can import

	use kernel::io::resource::{Resource, ResourceSize};

instead of having to write

	use kernel::io::{
	    resource::Resource,
	    ResourceSize,
	};

in the specific cases where you need ResourceSize because you are using
the Resource type. Therefore I think it makes sense to keep this
re-export indefinitely and it is *not* intended as a temporary re-export
for migration purposes.

Cc: stable@vger.kernel.org # for v6.18 [1]
Signed-off-by: Alice Ryhl 
Link: https://patch.msgid.link/20251112-resource-phys-typedefs-v2-2-538307384f82@google.com
Link: https://lore.kernel.org/all/20251112-resource-phys-typedefs-v2-0-538307384f82@google.com/ [1]
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: io: define ResourceSize as resource_size_t

2026-01-02T11:57:05+00:00

commit 919b72922717e396be9435c83916b9969505bd23 upstream.

These typedefs are always equivalent so this should not change anything,
but the code makes a lot more sense like this.

Cc: stable@vger.kernel.org
Signed-off-by: Alice Ryhl 
Fixes: 493fc33ec252 ("rust: io: add resource abstraction")
Link: https://patch.msgid.link/20251112-resource-phys-typedefs-v2-1-538307384f82@google.com
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust: dma: add helpers for architectures without CONFIG_HAS_DMA

2026-01-02T11:57:05+00:00

commit d8932355f8c5673106eca49abd142f8fe0c1fe8b upstream.

Add dma_set_mask(), dma_set_coherent_mask(), dma_map_sgtable(), and
dma_max_mapping_size() helpers to fix a build error when
CONFIG_HAS_DMA is not enabled.

Note that when CONFIG_HAS_DMA is enabled, they are included in both
bindings_generated.rs and bindings_helpers_generated.rs. The former
takes precedence so behavior remains unchanged in that case.

This fixes the following build error on UML:

error[E0425]: cannot find function `dma_set_mask` in crate `bindings`
     --> rust/kernel/dma.rs:46:38
      |
   46 |         to_result(unsafe { bindings::dma_set_mask(self.as_ref().as_raw(), mask.value()) })
      |                                      ^^^^^^^^^^^^ help: a function with a similar name exists: `xa_set_mark`
      |
     ::: rust/bindings/bindings_generated.rs:24690:5
      |
24690 |     pub fn xa_set_mark(arg1: *mut xarray, index: ffi::c_ulong, arg2: xa_mark_t);
      |     ---------------------------------------------------------------------------- similarly named function `xa_set_mark` defined here

error[E0425]: cannot find function `dma_set_coherent_mask` in crate `bindings`
     --> rust/kernel/dma.rs:63:38
      |
   63 |         to_result(unsafe { bindings::dma_set_coherent_mask(self.as_ref().as_raw(), mask.value()) })
      |                                      ^^^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `dma_coherent_ok`
      |
     ::: rust/bindings/bindings_generated.rs:52745:5
      |
52745 |     pub fn dma_coherent_ok(dev: *mut device, phys: phys_addr_t, size: usize) -> bool_;
      |     ---------------------------------------------------------------------------------- similarly named function `dma_coherent_ok` defined here

error[E0425]: cannot find function `dma_map_sgtable` in crate `bindings`
    --> rust/kernel/scatterlist.rs:212:23
     |
 212 |               bindings::dma_map_sgtable(dev.as_raw(), sgt.as_ptr(), dir.into(), 0)
     |                         ^^^^^^^^^^^^^^^ help: a function with a similar name exists: `dma_unmap_sgtable`
     |
    ::: rust/bindings/bindings_helpers_generated.rs:1351:5
     |
1351 | /     pub fn dma_unmap_sgtable(
1352 | |         dev: *mut device,
1353 | |         sgt: *mut sg_table,
1354 | |         dir: dma_data_direction,
1355 | |         attrs: ffi::c_ulong,
1356 | |     );
     | |______- similarly named function `dma_unmap_sgtable` defined here

error[E0425]: cannot find function `dma_max_mapping_size` in crate `bindings`
   --> rust/kernel/scatterlist.rs:356:52
    |
356 |         let max_segment = match unsafe { bindings::dma_max_mapping_size(dev.as_raw()) } {
    |                                                    ^^^^^^^^^^^^^^^^^^^^ not found in `bindings`

error: aborting due to 4 previous errors

Cc: stable@vger.kernel.org # v6.17+
Fixes: 101d66828a4ee ("rust: dma: add DMA addressing capabilities")
Signed-off-by: FUJITA Tomonori 
Reviewed-by: David Gow 
Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20251204160639.364936-1-fujita.tomonori@gmail.com
[ Use relative paths in the error splat; add 'dma' prefix. - Danilo ]
Signed-off-by: Danilo Krummrich 
Signed-off-by: Greg Kroah-Hartman

rust/drm/gem: Fix missing header in `Object` rustdoc

2026-01-02T11:57:05+00:00

commit e54ad0cd3673c93cdafda58505eaa81610fe3aef upstream.

Invariants should be prefixed with a # to turn it into a header.

There are no functional changes in this patch.

Cc: stable@vger.kernel.org
Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction")
Signed-off-by: Lyude Paul 
Link: https://patch.msgid.link/20251107202603.465932-1-lyude@redhat.com
Signed-off-by: Alice Ryhl 
Signed-off-by: Greg Kroah-Hartman

rust: Add -fno-isolate-erroneous-paths-dereference to bindgen_skip_c_flags

2025-11-10T00:37:06+00:00

It's used to work around an objtool issue since commit abb2a5572264
("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference"), but
it's then passed to bindgen and cause an error because Clang does not
have this option.

Fixes: abb2a5572264 ("LoongArch: Add cflag -fno-isolate-erroneous-paths-dereference")
Acked-by: Miguel Ojeda 
Tested-by: Mingcong Bai 
Signed-off-by: Xi Ruoyao 
Signed-off-by: Huacai Chen

rust: kbuild: workaround `rustdoc` doctests modifier bug

2025-11-03T23:00:06+00:00

The `rustdoc` modifiers bug [1] was fixed in Rust 1.90.0 [2], for which
we added a workaround in commit abbf9a449441 ("rust: workaround `rustdoc`
target modifiers bug").

However, `rustdoc`'s doctest generation still has a similar issue [3],
being fixed at [4], which does not affect us because we apply the
workaround to both, and now, starting with Rust 1.91.0 (released
2025-10-30), `-Zsanitizer` is a target modifier too [5], which means we
fail with:

      RUSTDOC TK rust/kernel/lib.rs
    error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `kernel`
     --> rust/kernel/lib.rs:3:1
      |
    3 | //! The `kernel` crate.
      | ^
      |
      = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
      = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core`
      = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core`
      = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error

A simple way around is to add the sanitizer to the list in the existing
workaround (especially if we had not started to pass the sanitizer
flags in the previous commit, since in that case that would not be
necessary). However, that still applies the workaround in more cases
than necessary.

Instead, only modify the doctests flags to ignore the check for
sanitizers, so that it is more local (and thus the compiler keeps checking
it for us in the normal `rustdoc` calls). Since the previous commit
already treated the `rustdoc` calls as kernel objects, this should allow
us in the future to easily remove this workaround when the time comes.

By the way, the `-Cunsafe-allow-abi-mismatch` flag overwrites previous
ones rather than appending, so it needs to be all done in the same flag.
Moreover, unknown modifiers are rejected, and thus we have to gate based
on the version too.

Finally, `-Zsanitizer-cfi-normalize-integers` is not affected (in Rust
1.91.0), so it is not needed in the workaround for the moment.

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/issues/144521 [1]
Link: https://github.com/rust-lang/rust/pull/144523 [2]
Link: https://github.com/rust-lang/rust/issues/146465 [3]
Link: https://github.com/rust-lang/rust/pull/148068 [4]
Link: https://github.com/rust-lang/rust/pull/138736 [5]
Reviewed-by: Alice Ryhl 
Tested-by: Justin M. Forbes 
Link: https://patch.msgid.link/20251102212853.1505384-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

rust: kbuild: treat `build_error` and `rustdoc` as kernel objects

2025-11-03T23:00:03+00:00

Even if normally `build_error` isn't a kernel object, it should still
be treated as such so that we pass the same flags. Similarly, `rustdoc`
targets are never kernel objects, but we need to treat them as such.

Otherwise, starting with Rust 1.91.0 (released 2025-10-30), `rustc`
will complain about missing sanitizer flags since `-Zsanitizer` is a
target modifier too [1]:

    error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `build_error`
     --> rust/build_error.rs:3:1
      |
    3 | //! Build-time error.
      | ^
      |
      = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
      = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core`
      = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core`
      = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error

Thus explicitly mark them as kernel objects.

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/138736 [1]
Reviewed-by: Alice Ryhl 
Tested-by: Justin M. Forbes 
Link: https://patch.msgid.link/20251102212853.1505384-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

rust: condvar: fix broken intra-doc link

2025-11-02T22:18:42+00:00

The future move of pin-init to `syn` uncovers the following broken
intra-doc link:

    error: unresolved link to `crate::pin_init`
      --> rust/kernel/sync/condvar.rs:39:40
       |
    39 | /// instances is with the [`pin_init`](crate::pin_init!) and [`new_condvar`] macros.
       |                                        ^^^^^^^^^^^^^^^^ no item named `pin_init` in module `kernel`
       |
       = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
       = help: to override `-D warnings` add `#[allow(rustdoc::broken_intra_doc_links)]`

Currently, when rendered, the link points to a literal `crate::pin_init!`
URL.

Thus fix it.

Cc: stable@vger.kernel.org
Fixes: 129e97be8e28 ("rust: pin-init: fix documentation links")
Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20251029073344.349341-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda