From: "tip-bot2 for Alice Ryhl" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Benno Lossin <lossin@kernel.org>,
Daniel Almeida <daniel.almeida@collabora.com>,
Alice Ryhl <aliceryhl@google.com>,
Boqun Feng <boqun.feng@gmail.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: locking/core] rust: sync: Refactor static_lock_class!() macro
Date: Tue, 13 Jan 2026 10:50:12 -0000 [thread overview]
Message-ID: <176830141294.510.3601508695543927072.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20250811-lock-class-key-cleanup-v3-1-b12967ee1ca2@google.com>
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 86f4a271dc1962e389ea512d07a77626dbd8c1d8
Gitweb: https://git.kernel.org/tip/86f4a271dc1962e389ea512d07a77626dbd8c1d8
Author: Alice Ryhl <aliceryhl@google.com>
AuthorDate: Mon, 11 Aug 2025 12:14:41
Committer: Boqun Feng <boqun.feng@gmail.com>
CommitterDate: Fri, 09 Jan 2026 19:01:40 +08:00
rust: sync: Refactor static_lock_class!() macro
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 5df87e2..1dfbee8 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 @@ impl PinnedDrop for LockClassKey {
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)
}};
}
next prev parent reply other threads:[~2026-01-13 10:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 12:14 [PATCH v3 0/2] Clean up Rust LockClassKey Alice Ryhl
2025-08-11 12:14 ` [PATCH v3 1/2] rust: sync: refactor static_lock_class!() macro Alice Ryhl
2026-01-13 10:50 ` tip-bot2 for Alice Ryhl [this message]
2025-08-11 12:14 ` [PATCH v3 2/2] rust: sync: clean up LockClassKey and its docs Alice Ryhl
2026-01-13 10:50 ` [tip: locking/core] rust: sync: Clean " tip-bot2 for Alice Ryhl
2025-08-12 15:51 ` [PATCH v3 0/2] Clean up Rust LockClassKey Boqun Feng
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=176830141294.510.3601508695543927072.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=aliceryhl@google.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=x86@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
all inboxes | Powered by JetHome®