[PATCH v2] rust: xarray: fix false positive lockdep warnings

[PATCH v2] rust: xarray: fix false positive lockdep warnings

[Andreas Hindborg]

`xa_init_flags()` is a static inline that expands `spin_lock_init()`,
which generates a single static `lock_class_key` per compilation unit.
When used through the Rust binding helper, every Rust `XArray`
instance ends up sharing that single key. Lockdep then sees concurrent
locking of distinct Rust `XArray`s as recursive locking on the same
class and emits false-positive lock-ordering reports.

Add a custom helper `xa_init_flags_with_key()` that mirrors
`xa_init_flags()` but takes an explicit name and `struct
lock_class_key` from the caller. Update `XArray::new` to take a name
and a `LockClassKey`, and add a `new_xarray!` macro that uses
`optional_name!` and `static_lock_class!` to generate a unique class
per instantiation site.

Remove the now unused `rust_helper_xa_init_flags`.

This was previously part of the series at [1].

Link: https://lore.kernel.org/r/20251203-xarray-entry-send-v1-0-9e5ffd5e3cf0@kernel.org [1]
Fixes: 210b81578efbe ("rust: xarray: Add an abstraction for XArray")
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Tamir Duberstein <tamird@kernel.org>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
---
Changes in v2:
- Use a C helper `xa_init_flags_with_key()` that calls
  `lockdep_set_class_and_name()` to install the caller-supplied key,
  rather than calling `__spin_lock_init()` from Rust. Mirrors the
  `init_work_with_key()` pattern in `rust/helpers/workqueue.c`
  (suggested by Alice Ryhl, seconded by Tamir Duberstein).
- Add `Suggested-by: Alice Ryhl <aliceryhl@google.com>`.
- Correct Tamir's `Acked-by:` email to `tamird@kernel.org`.
- Rebase on v7.1-rc2.
- Link to v1: https://msgid.link/20260206-xarray-lockdep-fix-v1-1-13315951b836@kernel.org

To: Miguel Ojeda <ojeda@kernel.org>
To: Boqun Feng <boqun@kernel.org>
To: Gary Guo <gary@garyguo.net>
To: Björn Roy Baron <bjorn3_gh@protonmail.com>
To: Benno Lossin <lossin@kernel.org>
To: Andreas Hindborg <a.hindborg@kernel.org>
To: Alice Ryhl <aliceryhl@google.com>
To: Trevor Gross <tmgross@umich.edu>
To: Danilo Krummrich <dakr@kernel.org>
To: Tamir Duberstein <tamird@kernel.org>
Cc: rust-for-linux@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 rust/helpers/xarray.c | 16 ++++++++++++++--
 rust/kernel/xarray.rs | 28 ++++++++++++++++++++++++----
 2 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/rust/helpers/xarray.c b/rust/helpers/xarray.c
index 08979b304341..dce8b36492e6 100644
--- a/rust/helpers/xarray.c
+++ b/rust/helpers/xarray.c
@@ -7,9 +7,21 @@ __rust_helper int rust_helper_xa_err(void *entry)
 	return xa_err(entry);
 }
 
-__rust_helper void rust_helper_xa_init_flags(struct xarray *xa, gfp_t flags)
+/*
+ * `xa_init_flags()` expands `spin_lock_init()`, which generates one static
+ * `lock_class_key` per compilation unit. Going through a single Rust binding
+ * helper would make every Rust `XArray` instance share that one key, causing
+ * false-positive lock-ordering reports from lockdep. Re-register the
+ * spinlock's lockdep class with a key supplied by the caller so each Rust
+ * instantiation site can have its own.
+ */
+__rust_helper void rust_helper_xa_init_flags_with_key(struct xarray *xa,
+						      gfp_t flags,
+						      const char *name,
+						      struct lock_class_key *key)
 {
-	return xa_init_flags(xa, flags);
+	xa_init_flags(xa, flags);
+	lockdep_set_class_and_name(&xa->xa_lock, key, name);
 }
 
 __rust_helper int rust_helper_xa_trylock(struct xarray *xa)
diff --git a/rust/kernel/xarray.rs b/rust/kernel/xarray.rs
index 46e5f43223fe..78c9fbe8f0aa 100644
--- a/rust/kernel/xarray.rs
+++ b/rust/kernel/xarray.rs
@@ -8,11 +8,26 @@
     alloc, bindings, build_assert,
     error::{Error, Result},
     ffi::c_void,
+    str::{CStr, CStrExt},
+    sync::LockClassKey,
     types::{ForeignOwnable, NotThreadSafe, Opaque},
 };
 use core::{iter, marker::PhantomData, pin::Pin, ptr::NonNull};
 use pin_init::{pin_data, pin_init, pinned_drop, PinInit};
 
+/// Creates a [`XArray`] initialiser with the given name and a newly-created lock class.
+///
+/// It uses the name if one is given, otherwise it generates one based on the file name and line
+/// number.
+#[macro_export]
+macro_rules! new_xarray {
+    ($kind:expr $(, $name:literal)? $(,)?) => {
+        $crate::xarray::XArray::new(
+            $kind, $crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_xarray;
+
 /// An array which efficiently maps sparse integer indices to owned objects.
 ///
 /// This is similar to a [`crate::alloc::kvec::Vec<Option<T>>`], but more efficient when there are
@@ -27,9 +42,10 @@
 ///
 /// ```rust
 /// use kernel::alloc::KBox;
-/// use kernel::xarray::{AllocKind, XArray};
+/// use kernel::xarray::{new_xarray, AllocKind, XArray};
 ///
-/// let xa = KBox::pin_init(XArray::new(AllocKind::Alloc1), GFP_KERNEL)?;
+/// let xa: Pin<KBox<XArray<KBox<u32>>>> =
+///     KBox::pin_init(new_xarray!(AllocKind::Alloc1), GFP_KERNEL)?;
 ///
 /// let dead = KBox::new(0xdead, GFP_KERNEL)?;
 /// let beef = KBox::new(0xbeef, GFP_KERNEL)?;
@@ -86,7 +102,11 @@ pub enum AllocKind {
 
 impl<T: ForeignOwnable> XArray<T> {
     /// Creates a new initializer for this type.
-    pub fn new(kind: AllocKind) -> impl PinInit<Self> {
+    pub fn new(
+        kind: AllocKind,
+        name: &'static CStr,
+        key: Pin<&'static LockClassKey>,
+    ) -> impl PinInit<Self> {
         let flags = match kind {
             AllocKind::Alloc => bindings::XA_FLAGS_ALLOC,
             AllocKind::Alloc1 => bindings::XA_FLAGS_ALLOC1,
@@ -96,7 +116,7 @@ pub fn new(kind: AllocKind) -> impl PinInit<Self> {
             //
             // INVARIANT: `xa` is initialized here to an empty, valid [`bindings::xarray`].
             xa <- Opaque::ffi_init(|xa| unsafe {
-                bindings::xa_init_flags(xa, flags)
+                bindings::xa_init_flags_with_key(xa, flags, name.as_char_ptr(), key.as_ptr())
             }),
             _p: PhantomData,
         })

---
base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
change-id: 20260206-xarray-lockdep-fix-10f1cc68e5d7

Best regards,
--  
Andreas Hindborg <a.hindborg@kernel.org>

Re: [PATCH v2] rust: xarray: fix false positive lockdep warnings

[Alice Ryhl]

On Fri, Jun 05, 2026 at 11:14:29AM +0200, Andreas Hindborg wrote:
> `xa_init_flags()` is a static inline that expands `spin_lock_init()`,
> which generates a single static `lock_class_key` per compilation unit.
> When used through the Rust binding helper, every Rust `XArray`
> instance ends up sharing that single key. Lockdep then sees concurrent
> locking of distinct Rust `XArray`s as recursive locking on the same
> class and emits false-positive lock-ordering reports.
> 
> Add a custom helper `xa_init_flags_with_key()` that mirrors
> `xa_init_flags()` but takes an explicit name and `struct
> lock_class_key` from the caller. Update `XArray::new` to take a name
> and a `LockClassKey`, and add a `new_xarray!` macro that uses
> `optional_name!` and `static_lock_class!` to generate a unique class
> per instantiation site.
> 
> Remove the now unused `rust_helper_xa_init_flags`.
> 
> This was previously part of the series at [1].
> 
> Link: https://lore.kernel.org/r/20251203-xarray-entry-send-v1-0-9e5ffd5e3cf0@kernel.org [1]
> Fixes: 210b81578efbe ("rust: xarray: Add an abstraction for XArray")
> Suggested-by: Alice Ryhl <aliceryhl@google.com>
> Acked-by: Tamir Duberstein <tamird@kernel.org>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Re: [PATCH v2] rust: xarray: fix false positive lockdep warnings

[Tamir Duberstein]

On Fri, 05 Jun 2026 11:14:29 +0200, Andreas Hindborg <a.hindborg@kernel.org> wrote:
> rust: xarray: fix false positive lockdep warnings

Reviewed-by: Tamir Duberstein <tamird@kernel.org>

-- 
Tamir Duberstein <tamird@kernel.org>

Re: [PATCH v2] rust: xarray: fix false positive lockdep warnings

[Tamir Duberstein]

On Fri, 05 Jun 2026 11:14:29 +0200, Andreas Hindborg <a.hindborg@kernel.org> wrote:
> diff --git a/rust/helpers/xarray.c b/rust/helpers/xarray.c
> index 08979b304341..dce8b36492e6 100644
> --- a/rust/helpers/xarray.c
> +++ b/rust/helpers/xarray.c
> @@ -7,9 +7,21 @@ __rust_helper int rust_helper_xa_err(void *entry)
>  	return xa_err(entry);
>  }
>  
> -__rust_helper void rust_helper_xa_init_flags(struct xarray *xa, gfp_t flags)
> +/*
> + * `xa_init_flags()` expands `spin_lock_init()`, which generates one static
> + * `lock_class_key` per compilation unit. Going through a single Rust binding
> + * helper would make every Rust `XArray` instance share that one key, causing
> + * false-positive lock-ordering reports from lockdep. Re-register the
> + * spinlock's lockdep class with a key supplied by the caller so each Rust
> + * instantiation site can have its own.
> + */

This is an implementation comment rather than a useful comment for the
caller.

>
> diff --git a/rust/kernel/xarray.rs b/rust/kernel/xarray.rs
> index 46e5f43223fe..78c9fbe8f0aa 100644
> --- a/rust/kernel/xarray.rs
> +++ b/rust/kernel/xarray.rs
> @@ -27,9 +42,10 @@
>  ///
>  /// ```rust
>  /// use kernel::alloc::KBox;
> -/// use kernel::xarray::{AllocKind, XArray};
> +/// use kernel::xarray::{new_xarray, AllocKind, XArray};
>  ///
> -/// let xa = KBox::pin_init(XArray::new(AllocKind::Alloc1), GFP_KERNEL)?;
> +/// let xa: Pin<KBox<XArray<KBox<u32>>>> =
> +///     KBox::pin_init(new_xarray!(AllocKind::Alloc1), GFP_KERNEL)?;

Was it necessary to add this type ascription on the LHS?

-- 
Tamir Duberstein <tamird@kernel.org>

Re: [PATCH v2] rust: xarray: fix false positive lockdep warnings

[Tamir Duberstein]

On Fri, Jun 5, 2026 at 8:09 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> On Fri, 05 Jun 2026 11:14:29 +0200, Andreas Hindborg <a.hindborg@kernel.org> wrote:
> > rust: xarray: fix false positive lockdep warnings
>
> Reviewed-by: Tamir Duberstein <tamird@kernel.org>
>
> --
> Tamir Duberstein <tamird@kernel.org>

Apologies for the duplicate emails, it looks like a bug in b4[0].

Link: https://lore.kernel.org/all/20260605-review-double-review-email-v1-1-d52c2ca14024@kernel.org/
[0]