From: Boqun Feng <boqun.feng@gmail.com>
To: "Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@kernel.org>
Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Miguel Ojeda" <ojeda@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Alice Ryhl" <aliceryhl@google.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Benno Lossin" <lossin@kernel.org>,
"Danilo Krummrich" <dakr@kernel.org>,
Daniel Almeida <daniel.almeida@collabora.com>,
Boqun Feng <boqun.feng@gmail.com>
Subject: [PATCH 01/36] rust: sync: Refactor static_lock_class!() macro
Date: Sun, 11 Jan 2026 19:57:33 +0800 [thread overview]
Message-ID: <20260111115808.5702-2-boqun.feng@gmail.com> (raw)
In-Reply-To: <20260111115808.5702-1-boqun.feng@gmail.com>
From: Alice Ryhl <aliceryhl@google.com>
By introducing a new_static() constructor, the macro does not need to go
through MaybeUninit::uninit().assume_init(), which is a pattern that is
best avoided when possible.
The safety comment not only requires that the value is leaked, but also
that it is stored in the right portion of memory. This is so that the
lockdep static_obj() check will succeed when using this constructor. One
could argue that lockdep detects this scenario, so that safety
requirement isn't needed. However, it simplifies matters to require that
static_obj() will succeed and it's not a burdensome requirement on the
caller.
Suggested-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20250811-lock-class-key-cleanup-v3-1-b12967ee1ca2@google.com
---
rust/kernel/sync.rs | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 5df87e2bd212..1dfbee8e9d00 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -45,6 +45,21 @@ pub struct LockClassKey {
unsafe impl Sync for LockClassKey {}
impl LockClassKey {
+ /// Initializes a statically allocated lock class key.
+ ///
+ /// This is usually used indirectly through the [`static_lock_class!`] macro.
+ ///
+ /// # Safety
+ ///
+ /// * Before using the returned value, it must be pinned in a static memory location.
+ /// * The destructor must never run on the returned `LockClassKey`.
+ #[doc(hidden)]
+ pub const unsafe fn new_static() -> Self {
+ LockClassKey {
+ inner: Opaque::uninit(),
+ }
+ }
+
/// Initializes a dynamically allocated lock class key. In the common case of using a
/// statically allocated lock class key, the static_lock_class! macro should be used instead.
///
@@ -101,12 +116,9 @@ fn drop(self: Pin<&mut Self>) {
macro_rules! static_lock_class {
() => {{
static CLASS: $crate::sync::LockClassKey =
- // Lockdep expects uninitialized memory when it's handed a statically allocated `struct
- // lock_class_key`.
- //
- // SAFETY: `LockClassKey` transparently wraps `Opaque` which permits uninitialized
- // memory.
- unsafe { ::core::mem::MaybeUninit::uninit().assume_init() };
+ // SAFETY: The returned `LockClassKey` is stored in static memory and we pin it. Drop
+ // never runs on a static global.
+ unsafe { $crate::sync::LockClassKey::new_static() };
$crate::prelude::Pin::static_ref(&CLASS)
}};
}
--
2.51.0
next prev parent reply other threads:[~2026-01-11 11:58 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-11 11:57 [GIT PULL][PATCH 00/36] Rust synchronization changes for v7.0 Boqun Feng
2026-01-11 11:57 ` Boqun Feng [this message]
2026-01-11 11:57 ` [PATCH 02/36] rust: sync: Clean up LockClassKey and its docs Boqun Feng
2026-01-11 12:01 ` [PATCH 03/36] rust: sync: set_once: Implement Send and Sync Boqun Feng
2026-01-11 12:01 ` [PATCH 04/36] rust: sync: Implement Unpin for ARef Boqun Feng
2026-01-11 12:01 ` [PATCH 05/36] rust: helpers: Add i8/i16 atomic_read_acquire/atomic_set_release helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 06/36] rust: helpers: Add i8/i16 relaxed atomic helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 07/36] rust: helpers: Add i8/i16 atomic xchg helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 08/36] rust: helpers: Add i8/i16 atomic xchg_acquire helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 09/36] rust: helpers: Add i8/i16 atomic xchg_release helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 10/36] rust: helpers: Add i8/i16 atomic xchg_relaxed helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 11/36] rust: helpers: Add i8/i16 atomic try_cmpxchg helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 12/36] rust: helpers: Add i8/i16 atomic try_cmpxchg_acquire helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 13/36] rust: helpers: Add i8/i16 atomic try_cmpxchg_release helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 14/36] rust: helpers: Add i8/i16 atomic try_cmpxchg_relaxed helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 15/36] rust: sync: atomic: Prepare AtomicOps macros for i8/i16 support Boqun Feng
2026-01-11 12:01 ` [PATCH 16/36] arch: um/x86: Select ARCH_SUPPORTS_ATOMIC_RMW for UML_X86 Boqun Feng
2026-01-11 12:01 ` [PATCH 17/36] rust: sync: atomic: Add i8/i16 load and store support Boqun Feng
2026-01-11 12:01 ` [PATCH 18/36] rust: sync: atomic: Add store_release/load_acquire tests Boqun Feng
2026-01-11 12:01 ` [PATCH 19/36] rust: sync: atomic: Add i8/i16 xchg and cmpxchg support Boqun Feng
2026-01-11 12:01 ` [PATCH 20/36] rust: sync: atomic: Add atomic bool support via i8 representation Boqun Feng
2026-01-11 12:01 ` [PATCH 21/36] rust: sync: atomic: Add atomic bool tests Boqun Feng
2026-01-11 12:01 ` [PATCH 22/36] rust: list: Switch to kernel::sync atomic primitives Boqun Feng
2026-01-11 12:01 ` [PATCH 23/36] rust_binder: " Boqun Feng
2026-01-11 12:01 ` [PATCH 24/36] rust: barrier: Add __rust_helper to helpers Boqun Feng
2026-01-11 12:01 ` [PATCH 25/36] rust: blk: " Boqun Feng
2026-01-11 12:01 ` [PATCH 26/36] rust: completion: " Boqun Feng
2026-01-11 12:02 ` [PATCH 27/36] rust: cpu: " Boqun Feng
2026-01-11 12:02 ` [PATCH 28/36] rust: processor: " Boqun Feng
2026-01-11 12:02 ` [PATCH 29/36] rust: rcu: " Boqun Feng
2026-01-11 12:02 ` [PATCH 30/36] rust: refcount: " Boqun Feng
2026-01-11 12:02 ` [PATCH 31/36] rust: sync: " Boqun Feng
2026-01-11 12:02 ` [PATCH 32/36] rust: task: " Boqun Feng
2026-01-11 12:02 ` [PATCH 33/36] rust: time: " Boqun Feng
2026-01-11 12:02 ` [PATCH 34/36] rust: wait: " Boqun Feng
2026-01-11 12:02 ` [PATCH 35/36] rust: helpers: Move #define __rust_helper out of atomic.c Boqun Feng
2026-01-11 12:02 ` [PATCH 36/36] rust: sync: Inline various lock related methods Boqun Feng
2026-01-13 10:10 ` [GIT PULL][PATCH 00/36] Rust synchronization changes for v7.0 Boqun Feng
2026-01-13 10:43 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260111115808.5702-2-boqun.feng@gmail.com \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox