linux-stable.git/rust/kernel, 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/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: 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

rust: devres: fix private intra-doc link

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

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

    error: public documentation for `Devres` links to private item `Self::inner`
       --> rust/kernel/devres.rs:106:7
        |
    106 | /// [`Self::inner`] is guaranteed to be initialized and is always accessed read-only.
        |       ^^^^^^^^^^^ this item is private
        |
        = note: this link will resolve properly if you pass `--document-private-items`
        = note: `-D rustdoc::private-intra-doc-links` implied by `-D warnings`
        = help: to override `-D warnings` add `#[allow(rustdoc::private_intra_doc_links)]`

Currently, when rendered, the link points to "nowhere" (an inexistent
anchor for a "method").

Thus fix it.

Cc: stable@vger.kernel.org
Fixes: f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc")
Acked-by: Danilo Krummrich 
Link: https://patch.msgid.link/20251029071406.324511-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

Merge tag 'driver-core-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core

2025-10-25T18:03:46+00:00

Pull driver core fixes from Danilo Krummrich:

 - In Device::parent(), do not make any assumptions on the device
   context of the parent device

 - Check visibility before changing ownership of a sysfs attribute
   group

 - In topology_parse_cpu_capacity(), replace an incorrect usage of
   PTR_ERR_OR_ZERO() with IS_ERR_OR_NULL()

 - In devcoredump, fix a circular locking dependency between
   struct devcd_entry::mutex and kernfs

 - Do not warn about a pending fw_devlink sync state

* tag 'driver-core-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
  arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
  rust: device: fix device context of Device::parent()
  sysfs: check visibility before changing group attribute ownership
  devcoredump: Fix circular locking dependency with devcd->mutex.
  driver core: fw_devlink: Don't warn about sync_state() pending

rust: device: fix device context of Device::parent()

2025-10-17T21:24:19+00:00

Regardless of the DeviceContext of a device, we can't give any
guarantees about the DeviceContext of its parent device.

This is very subtle, since it's only caused by a simple typo, i.e.

	 Self::from_raw(parent)

which preserves the DeviceContext in this case, vs.

	 Device::from_raw(parent)

which discards the DeviceContext.

(I should have noticed it doing the correct thing in auxiliary::Device
subsequently, but somehow missed it.)

Hence, fix both Device::parent() and auxiliary::Device::parent().

Cc: stable@vger.kernel.org
Fixes: a4c9f71e3440 ("rust: device: implement Device::parent()")
Reviewed-by: Alice Ryhl 
Reviewed-by: Alexandre Courbot 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Danilo Krummrich

rust: bitmap: fix formatting

2025-10-17T11:02:22+00:00

We do our best to keep the repository `rustfmt`-clean, thus run the tool
to fix the formatting issue.

Link: https://docs.kernel.org/rust/coding-guidelines.html#style-formatting
Link: https://rust-for-linux.com/contributing#submit-checklist-addendum
Fixes: 0f5878834d6c ("rust: bitmap: clean Rust 1.92.0 `unused_unsafe` warning")
Reviewed-by: Burak Emir 
Signed-off-by: Miguel Ojeda