* [PATCH locking 07/11] rust: sync: Add accessor for the lock behind a given guard
2025-03-07 23:26 ` [PATCH locking 00/11] " Boqun Feng
@ 2025-03-07 23:26 ` Boqun Feng
2025-03-07 23:26 ` [PATCH locking 08/11] rust: sync: lock: Add an example for Guard::lock_ref() Boqun Feng
` (4 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Boqun Feng @ 2025-03-07 23:26 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Will Deacon, Waiman Long, linux-kernel, Alice Ryhl, Fiona Behrens,
Boqun Feng, Ingo Molnar, Miguel Ojeda, Alex Gaynor, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, open list:RUST
From: Alice Ryhl <aliceryhl@google.com>
In order to assert a particular `Guard` is associated with a particular
`Lock`, add an accessor to obtain a reference to the underlying `Lock`
of a `Guard`.
Binder needs this assertion to ensure unsafe list operations are done
with the correct lock held.
[Boqun: Capitalize the title and reword the commit log]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20250205-guard-get-lock-v2-1-ba32a8c1d5b7@google.com
---
rust/kernel/sync/lock.rs | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index eb80048e0110..8e7e6d5f61e4 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -199,7 +199,12 @@ pub struct Guard<'a, T: ?Sized, B: Backend> {
// SAFETY: `Guard` is sync when the data protected by the lock is also sync.
unsafe impl<T: Sync + ?Sized, B: Backend> Sync for Guard<'_, T, B> {}
-impl<T: ?Sized, B: Backend> Guard<'_, T, B> {
+impl<'a, T: ?Sized, B: Backend> Guard<'a, T, B> {
+ /// Returns the lock that this guard originates from.
+ pub fn lock_ref(&self) -> &'a Lock<T, B> {
+ self.lock
+ }
+
pub(crate) fn do_unlocked<U>(&mut self, cb: impl FnOnce() -> U) -> U {
// SAFETY: The caller owns the lock, so it is safe to unlock it.
unsafe { B::unlock(self.lock.state.get(), &self.state) };
--
2.47.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH locking 08/11] rust: sync: lock: Add an example for Guard::lock_ref()
2025-03-07 23:26 ` [PATCH locking 00/11] " Boqun Feng
2025-03-07 23:26 ` [PATCH locking 07/11] rust: sync: Add accessor for the lock behind a given guard Boqun Feng
@ 2025-03-07 23:26 ` Boqun Feng
2025-03-07 23:26 ` [PATCH locking 09/11] rust: sync: condvar: Add wait_interruptible_freezable() Boqun Feng
` (3 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Boqun Feng @ 2025-03-07 23:26 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Will Deacon, Waiman Long, linux-kernel, Boqun Feng, Benno Lossin,
Alice Ryhl, Ingo Molnar, Miguel Ojeda, Alex Gaynor, Gary Guo,
Björn Roy Baron, Andreas Hindborg, Trevor Gross,
open list:RUST
To provide examples on usage of `Guard::lock_ref()` along with the unit
test, an "assert a lock is held by a guard" example is added.
[boqun: Apply feedback from Benno]
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250223072114.3715-1-boqun.feng@gmail.com
---
rust/kernel/sync/lock.rs | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index 8e7e6d5f61e4..f53e87d04cd2 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -201,6 +201,30 @@ unsafe impl<T: Sync + ?Sized, B: Backend> Sync for Guard<'_, T, B> {}
impl<'a, T: ?Sized, B: Backend> Guard<'a, T, B> {
/// Returns the lock that this guard originates from.
+ ///
+ /// # Examples
+ ///
+ /// The following example shows how to use [`Guard::lock_ref()`] to assert the corresponding
+ /// lock is held.
+ ///
+ /// ```
+ /// # use kernel::{new_spinlock, stack_pin_init, sync::lock::{Backend, Guard, Lock}};
+ ///
+ /// fn assert_held<T, B: Backend>(guard: &Guard<'_, T, B>, lock: &Lock<T, B>) {
+ /// // Address-equal means the same lock.
+ /// assert!(core::ptr::eq(guard.lock_ref(), lock));
+ /// }
+ ///
+ /// // Creates a new lock on the stack.
+ /// stack_pin_init!{
+ /// let l = new_spinlock!(42)
+ /// }
+ ///
+ /// let g = l.lock();
+ ///
+ /// // `g` originates from `l`.
+ /// assert_held(&g, &l);
+ /// ```
pub fn lock_ref(&self) -> &'a Lock<T, B> {
self.lock
}
--
2.47.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH locking 09/11] rust: sync: condvar: Add wait_interruptible_freezable()
2025-03-07 23:26 ` [PATCH locking 00/11] " Boqun Feng
2025-03-07 23:26 ` [PATCH locking 07/11] rust: sync: Add accessor for the lock behind a given guard Boqun Feng
2025-03-07 23:26 ` [PATCH locking 08/11] rust: sync: lock: Add an example for Guard::lock_ref() Boqun Feng
@ 2025-03-07 23:26 ` Boqun Feng
2025-03-07 23:27 ` [PATCH locking 10/11] rust: lockdep: Remove support for dynamically allocated LockClassKeys Boqun Feng
` (2 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Boqun Feng @ 2025-03-07 23:26 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Will Deacon, Waiman Long, linux-kernel, Alice Ryhl, Boqun Feng,
Miguel Ojeda, Alex Gaynor, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Mitchell Levy,
Danilo Krummrich, Christian Brauner, Martin Rodriguez Reboredo,
open list:RUST
From: Alice Ryhl <aliceryhl@google.com>
To support waiting for a `CondVar` as a freezable process, add a
wait_interruptible_freezable() function.
Binder needs this function in the appropriate places to freeze a process
where some of its threads are blocked on the Binder driver.
[Boqun: Capitalize the title, reword the commit log and rephrase the
function doc comment with the impersonal style to align with rest of the
file]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20250204-condvar-freeze-v2-1-804483096260@google.com
---
rust/kernel/sync/condvar.rs | 23 ++++++++++++++++++++++-
rust/kernel/task.rs | 2 ++
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
index 7df565038d7d..5c1e546a26c3 100644
--- a/rust/kernel/sync/condvar.rs
+++ b/rust/kernel/sync/condvar.rs
@@ -11,7 +11,9 @@
init::PinInit,
pin_init,
str::CStr,
- task::{MAX_SCHEDULE_TIMEOUT, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE},
+ task::{
+ MAX_SCHEDULE_TIMEOUT, TASK_FREEZABLE, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE,
+ },
time::Jiffies,
types::Opaque,
};
@@ -159,6 +161,25 @@ pub fn wait_interruptible<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T,
crate::current!().signal_pending()
}
+ /// Releases the lock and waits for a notification in interruptible and freezable mode.
+ ///
+ /// The process is allowed to be frozen during this sleep. No lock should be held when calling
+ /// this function, and there is a lockdep assertion for this. Freezing a task that holds a lock
+ /// can trivially deadlock vs another task that needs that lock to complete before it too can
+ /// hit freezable.
+ #[must_use = "wait_interruptible_freezable returns if a signal is pending, so the caller must check the return value"]
+ pub fn wait_interruptible_freezable<T: ?Sized, B: Backend>(
+ &self,
+ guard: &mut Guard<'_, T, B>,
+ ) -> bool {
+ self.wait_internal(
+ TASK_INTERRUPTIBLE | TASK_FREEZABLE,
+ guard,
+ MAX_SCHEDULE_TIMEOUT,
+ );
+ crate::current!().signal_pending()
+ }
+
/// Releases the lock and waits for a notification in interruptible mode.
///
/// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
index 07bc22a7645c..ea43a3b8d9c5 100644
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@ -23,6 +23,8 @@
pub const TASK_INTERRUPTIBLE: c_int = bindings::TASK_INTERRUPTIBLE as c_int;
/// Bitmask for tasks that are sleeping in an uninterruptible state.
pub const TASK_UNINTERRUPTIBLE: c_int = bindings::TASK_UNINTERRUPTIBLE as c_int;
+/// Bitmask for tasks that are sleeping in a freezable state.
+pub const TASK_FREEZABLE: c_int = bindings::TASK_FREEZABLE as c_int;
/// Convenience constant for waking up tasks regardless of whether they are in interruptible or
/// uninterruptible sleep.
pub const TASK_NORMAL: c_uint = bindings::TASK_NORMAL as c_uint;
--
2.47.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH locking 10/11] rust: lockdep: Remove support for dynamically allocated LockClassKeys
2025-03-07 23:26 ` [PATCH locking 00/11] " Boqun Feng
` (2 preceding siblings ...)
2025-03-07 23:26 ` [PATCH locking 09/11] rust: sync: condvar: Add wait_interruptible_freezable() Boqun Feng
@ 2025-03-07 23:27 ` Boqun Feng
2025-03-07 23:27 ` [PATCH locking 11/11] rust: lockdep: Use Pin for all LockClassKey usages Boqun Feng
2025-03-08 0:01 ` [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15 Ingo Molnar
5 siblings, 0 replies; 14+ messages in thread
From: Boqun Feng @ 2025-03-07 23:27 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Will Deacon, Waiman Long, linux-kernel, Mitchell Levy, Alice Ryhl,
stable, Benno Lossin, Boqun Feng, Miguel Ojeda, Alex Gaynor,
Gary Guo, Björn Roy Baron, Andreas Hindborg, Trevor Gross,
Lyude Paul, Wedson Almeida Filho, Martin Rodriguez Reboredo,
open list:RUST
From: Mitchell Levy <levymitchell0@gmail.com>
Currently, dynamically allocated LockCLassKeys can be used from the Rust
side without having them registered. This is a soundness issue, so
remove them.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/rust-for-linux/20240815074519.2684107-3-nmi@metaspace.dk/
Cc: stable@vger.kernel.org
Fixes: 6ea5aa08857a ("rust: sync: introduce `LockClassKey`")
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20250207-rust-lockdep-v4-1-7a50a7e88656@gmail.com
---
rust/kernel/sync.rs | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 3498fb344dc9..16eab9138b2b 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -30,28 +30,20 @@
unsafe impl Sync for LockClassKey {}
impl LockClassKey {
- /// Creates a new lock class key.
- pub const fn new() -> Self {
- Self(Opaque::uninit())
- }
-
pub(crate) fn as_ptr(&self) -> *mut bindings::lock_class_key {
self.0.get()
}
}
-impl Default for LockClassKey {
- fn default() -> Self {
- Self::new()
- }
-}
-
/// Defines a new static lock class and returns a pointer to it.
#[doc(hidden)]
#[macro_export]
macro_rules! static_lock_class {
() => {{
- static CLASS: $crate::sync::LockClassKey = $crate::sync::LockClassKey::new();
+ static CLASS: $crate::sync::LockClassKey =
+ // SAFETY: lockdep expects uninitialized memory when it's handed a statically allocated
+ // lock_class_key
+ unsafe { ::core::mem::MaybeUninit::uninit().assume_init() };
&CLASS
}};
}
--
2.47.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH locking 11/11] rust: lockdep: Use Pin for all LockClassKey usages
2025-03-07 23:26 ` [PATCH locking 00/11] " Boqun Feng
` (3 preceding siblings ...)
2025-03-07 23:27 ` [PATCH locking 10/11] rust: lockdep: Remove support for dynamically allocated LockClassKeys Boqun Feng
@ 2025-03-07 23:27 ` Boqun Feng
2025-03-08 0:01 ` [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15 Ingo Molnar
5 siblings, 0 replies; 14+ messages in thread
From: Boqun Feng @ 2025-03-07 23:27 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Will Deacon, Waiman Long, linux-kernel, Mitchell Levy,
Benno Lossin, Boqun Feng, Miguel Ojeda, Alex Gaynor, Gary Guo,
Björn Roy Baron, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Ingo Molnar, Danilo Krummrich, Wedson Almeida Filho,
Christian Brauner, Lyude Paul, Martin Rodriguez Reboredo,
Konstantin Andrikopoulos, Roland Xu, open list:RUST
From: Mitchell Levy <levymitchell0@gmail.com>
Reintroduce dynamically-allocated LockClassKeys such that they are
automatically (de)registered. Require that all usages of LockClassKeys
ensure that they are Pin'd.
Currently, only `'static` LockClassKeys are supported, so Pin is
redundant. However, it is intended that dynamically-allocated
LockClassKeys will eventually be supported, so using Pin from the outset
will make that change simpler.
Closes: https://github.com/Rust-for-Linux/linux/issues/1102
Suggested-by: Benno Lossin <benno.lossin@proton.me>
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20250207-rust-lockdep-v4-2-7a50a7e88656@gmail.com
---
rust/helpers/helpers.c | 1 +
rust/helpers/sync.c | 13 ++++++++
rust/kernel/sync.rs | 57 +++++++++++++++++++++++++++++++--
rust/kernel/sync/condvar.rs | 5 ++-
rust/kernel/sync/lock.rs | 4 +--
rust/kernel/sync/lock/global.rs | 5 +--
rust/kernel/sync/poll.rs | 2 +-
rust/kernel/workqueue.rs | 2 +-
8 files changed, 77 insertions(+), 12 deletions(-)
create mode 100644 rust/helpers/sync.c
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 0640b7e115be..4c1a10a419cf 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -30,6 +30,7 @@
#include "signal.c"
#include "slab.c"
#include "spinlock.c"
+#include "sync.c"
#include "task.c"
#include "uaccess.c"
#include "vmalloc.c"
diff --git a/rust/helpers/sync.c b/rust/helpers/sync.c
new file mode 100644
index 000000000000..ff7e68b48810
--- /dev/null
+++ b/rust/helpers/sync.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/lockdep.h>
+
+void rust_helper_lockdep_register_key(struct lock_class_key *k)
+{
+ lockdep_register_key(k);
+}
+
+void rust_helper_lockdep_unregister_key(struct lock_class_key *k)
+{
+ lockdep_unregister_key(k);
+}
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 16eab9138b2b..4104bc26471a 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -5,6 +5,8 @@
//! This module contains the kernel APIs related to synchronisation that have been ported or
//! wrapped for usage by Rust code in the kernel.
+use crate::pin_init;
+use crate::prelude::*;
use crate::types::Opaque;
mod arc;
@@ -23,15 +25,64 @@
/// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
#[repr(transparent)]
-pub struct LockClassKey(Opaque<bindings::lock_class_key>);
+#[pin_data(PinnedDrop)]
+pub struct LockClassKey {
+ #[pin]
+ inner: Opaque<bindings::lock_class_key>,
+}
// SAFETY: `bindings::lock_class_key` is designed to be used concurrently from multiple threads and
// provides its own synchronization.
unsafe impl Sync for LockClassKey {}
impl LockClassKey {
+ /// 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.
+ ///
+ /// # Example
+ /// ```
+ /// # use kernel::{c_str, stack_pin_init};
+ /// # use kernel::alloc::KBox;
+ /// # use kernel::types::ForeignOwnable;
+ /// # use kernel::sync::{LockClassKey, SpinLock};
+ ///
+ /// let key = KBox::pin_init(LockClassKey::new_dynamic(), GFP_KERNEL)?;
+ /// let key_ptr = key.into_foreign();
+ ///
+ /// {
+ /// stack_pin_init!(let num: SpinLock<u32> = SpinLock::new(
+ /// 0,
+ /// c_str!("my_spinlock"),
+ /// // SAFETY: `key_ptr` is returned by the above `into_foreign()`, whose
+ /// // `from_foreign()` has not yet been called.
+ /// unsafe { <Pin<KBox<LockClassKey>> as ForeignOwnable>::borrow(key_ptr) }
+ /// ));
+ /// }
+ ///
+ /// // SAFETY: We dropped `num`, the only use of the key, so the result of the previous
+ /// // `borrow` has also been dropped. Thus, it's safe to use from_foreign.
+ /// unsafe { drop(<Pin<KBox<LockClassKey>> as ForeignOwnable>::from_foreign(key_ptr)) };
+ ///
+ /// # Ok::<(), Error>(())
+ /// ```
+ pub fn new_dynamic() -> impl PinInit<Self> {
+ pin_init!(Self {
+ // SAFETY: lockdep_register_key expects an uninitialized block of memory
+ inner <- Opaque::ffi_init(|slot| unsafe { bindings::lockdep_register_key(slot) })
+ })
+ }
+
pub(crate) fn as_ptr(&self) -> *mut bindings::lock_class_key {
- self.0.get()
+ self.inner.get()
+ }
+}
+
+#[pinned_drop]
+impl PinnedDrop for LockClassKey {
+ fn drop(self: Pin<&mut Self>) {
+ // SAFETY: self.as_ptr was registered with lockdep and self is pinned, so the address
+ // hasn't changed. Thus, it's safe to pass to unregister.
+ unsafe { bindings::lockdep_unregister_key(self.as_ptr()) }
}
}
@@ -44,7 +95,7 @@ macro_rules! static_lock_class {
// SAFETY: lockdep expects uninitialized memory when it's handed a statically allocated
// lock_class_key
unsafe { ::core::mem::MaybeUninit::uninit().assume_init() };
- &CLASS
+ $crate::prelude::Pin::static_ref(&CLASS)
}};
}
diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
index 5c1e546a26c3..fbf68ada582f 100644
--- a/rust/kernel/sync/condvar.rs
+++ b/rust/kernel/sync/condvar.rs
@@ -17,8 +17,7 @@
time::Jiffies,
types::Opaque,
};
-use core::marker::PhantomPinned;
-use core::ptr;
+use core::{marker::PhantomPinned, pin::Pin, ptr};
use macros::pin_data;
/// Creates a [`CondVar`] initialiser with the given name and a newly-created lock class.
@@ -103,7 +102,7 @@ unsafe impl Sync for CondVar {}
impl CondVar {
/// Constructs a new condvar initialiser.
- pub fn new(name: &'static CStr, key: &'static LockClassKey) -> impl PinInit<Self> {
+ pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self> {
pin_init!(Self {
_pin: PhantomPinned,
// SAFETY: `slot` is valid while the closure is called and both `name` and `key` have
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index f53e87d04cd2..360a10a9216d 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -12,7 +12,7 @@
str::CStr,
types::{NotThreadSafe, Opaque, ScopeGuard},
};
-use core::{cell::UnsafeCell, marker::PhantomPinned};
+use core::{cell::UnsafeCell, marker::PhantomPinned, pin::Pin};
use macros::pin_data;
pub mod mutex;
@@ -129,7 +129,7 @@ unsafe impl<T: ?Sized + Send, B: Backend> Sync for Lock<T, B> {}
impl<T, B: Backend> Lock<T, B> {
/// Constructs a new lock initialiser.
- pub fn new(t: T, name: &'static CStr, key: &'static LockClassKey) -> impl PinInit<Self> {
+ pub fn new(t: T, name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self> {
pin_init!(Self {
data: UnsafeCell::new(t),
_pin: PhantomPinned,
diff --git a/rust/kernel/sync/lock/global.rs b/rust/kernel/sync/lock/global.rs
index 480ee724e3cc..d65f94b5caf2 100644
--- a/rust/kernel/sync/lock/global.rs
+++ b/rust/kernel/sync/lock/global.rs
@@ -13,6 +13,7 @@
use core::{
cell::UnsafeCell,
marker::{PhantomData, PhantomPinned},
+ pin::Pin,
};
/// Trait implemented for marker types for global locks.
@@ -26,7 +27,7 @@ pub trait GlobalLockBackend {
/// The backend used for this global lock.
type Backend: Backend + 'static;
/// The class for this global lock.
- fn get_lock_class() -> &'static LockClassKey;
+ fn get_lock_class() -> Pin<&'static LockClassKey>;
}
/// Type used for global locks.
@@ -270,7 +271,7 @@ impl $crate::sync::lock::GlobalLockBackend for $name {
type Item = $valuety;
type Backend = $crate::global_lock_inner!(backend $kind);
- fn get_lock_class() -> &'static $crate::sync::LockClassKey {
+ fn get_lock_class() -> Pin<&'static $crate::sync::LockClassKey> {
$crate::static_lock_class!()
}
}
diff --git a/rust/kernel/sync/poll.rs b/rust/kernel/sync/poll.rs
index d5f17153b424..c4934f82d68b 100644
--- a/rust/kernel/sync/poll.rs
+++ b/rust/kernel/sync/poll.rs
@@ -89,7 +89,7 @@ pub struct PollCondVar {
impl PollCondVar {
/// Constructs a new condvar initialiser.
- pub fn new(name: &'static CStr, key: &'static LockClassKey) -> impl PinInit<Self> {
+ pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self> {
pin_init!(Self {
inner <- CondVar::new(name, key),
})
diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 0cd100d2aefb..6b6f3ad08951 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -369,7 +369,7 @@ unsafe impl<T: ?Sized, const ID: u64> Sync for Work<T, ID> {}
impl<T: ?Sized, const ID: u64> Work<T, ID> {
/// Creates a new instance of [`Work`].
#[inline]
- pub fn new(name: &'static CStr, key: &'static LockClassKey) -> impl PinInit<Self>
+ pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self>
where
T: WorkItem<ID>,
{
--
2.47.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15
2025-03-07 23:26 ` [PATCH locking 00/11] " Boqun Feng
` (4 preceding siblings ...)
2025-03-07 23:27 ` [PATCH locking 11/11] rust: lockdep: Use Pin for all LockClassKey usages Boqun Feng
@ 2025-03-08 0:01 ` Ingo Molnar
2025-03-08 0:04 ` Boqun Feng
5 siblings, 1 reply; 14+ messages in thread
From: Ingo Molnar @ 2025-03-08 0:01 UTC (permalink / raw)
To: Boqun Feng
Cc: Peter Zijlstra, Will Deacon, Waiman Long, linux-kernel,
Miguel Ojeda, Alex Gaynor, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
open list:RUST:Keyword:b(?i:rust)b
* Boqun Feng <boqun.feng@gmail.com> wrote:
> Hi Ingo & Peter,
>
> As discussed, I'm resending the pull request for lockdep and Rust
> locking for v6.15 in the format of email patches. I dropped one patch
> and will postpone it for v6.16 because of a bug [1], and I think the fix
> [2] needs more reviews.
>
> [1]: https://lore.kernel.org/lkml/20250306122413.GBZ8mT7Z61Tmgnh5Y9@fat_crate.local/
> [2]: https://lore.kernel.org/lkml/Z8t8imzJVhWyDvhC@boqun-archlinux/
>
> Regards,
> Boqun
>
> Alice Ryhl (2):
> rust: sync: Add accessor for the lock behind a given guard
> rust: sync: condvar: Add wait_interruptible_freezable()
>
> Boqun Feng (1):
> rust: sync: lock: Add an example for Guard::lock_ref()
>
> Mitchell Levy (2):
> rust: lockdep: Remove support for dynamically allocated LockClassKeys
> rust: lockdep: Use Pin for all LockClassKey usages
>
> Randy Dunlap (1):
> locking/rtmutex: Use struct keyword in kernel-doc comment
>
> Waiman Long (5):
> locking/semaphore: Use wake_q to wake up processes outside lock
> critical section
> locking/lock_events: Add locking events for rtmutex slow paths
> locking/lock_events: Add locking events for lockdep
> locking/lockdep: Disable KASAN instrumentation of lockdep.c
> locking/lockdep: Add kasan_check_byte() check in lock_acquire()
Thanks Boqun!
I've applied these 3 patches to the tip:locking/urgent tree:
locking/semaphore: Use wake_q to wake up processes outside lock critical section
locking/rtmutex: Use the 'struct' keyword in kernel-doc comment
rust: lockdep: Remove support for dynamically allocated LockClassKeys
As a general rule, if a patch is marked Cc: stable, it must also be
applied to current upstream.
I have applied the others to tip:locking/core:
locking/lock_events: Add locking events for rtmutex slow pathsa94d32446ab5 locking/lock_events: Add locking events for lockdep
locking/lockdep: Disable KASAN instrumentation of lockdep.c
locking/lockdep: Add kasan_check_byte() check in lock_acquire()
rust: sync: Add accessor for the lock behind a given guard
rust: sync: lock: Add an example for Guard:: Lock_ref()
rust: sync: condvar: Add wait_interruptible_freezable()
rust: lockdep: Use Pin for all LockClassKey usages
I cleaned up changelogs where necessary - for example we generally
don't include printk timestamps in changelogs, unless it's relevant,
plus there were a number of typos and grammar mistakes left in some of
the changelogs.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15
2025-03-08 0:01 ` [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15 Ingo Molnar
@ 2025-03-08 0:04 ` Boqun Feng
2025-03-08 0:11 ` Ingo Molnar
0 siblings, 1 reply; 14+ messages in thread
From: Boqun Feng @ 2025-03-08 0:04 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, Will Deacon, Waiman Long, linux-kernel,
Miguel Ojeda, Alex Gaynor, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
open list:RUST:Keyword:b(?i:rust)b
On Sat, Mar 08, 2025 at 01:01:45AM +0100, Ingo Molnar wrote:
>
> * Boqun Feng <boqun.feng@gmail.com> wrote:
>
> > Hi Ingo & Peter,
> >
> > As discussed, I'm resending the pull request for lockdep and Rust
> > locking for v6.15 in the format of email patches. I dropped one patch
> > and will postpone it for v6.16 because of a bug [1], and I think the fix
> > [2] needs more reviews.
> >
> > [1]: https://lore.kernel.org/lkml/20250306122413.GBZ8mT7Z61Tmgnh5Y9@fat_crate.local/
> > [2]: https://lore.kernel.org/lkml/Z8t8imzJVhWyDvhC@boqun-archlinux/
> >
> > Regards,
> > Boqun
> >
> > Alice Ryhl (2):
> > rust: sync: Add accessor for the lock behind a given guard
> > rust: sync: condvar: Add wait_interruptible_freezable()
> >
> > Boqun Feng (1):
> > rust: sync: lock: Add an example for Guard::lock_ref()
> >
> > Mitchell Levy (2):
> > rust: lockdep: Remove support for dynamically allocated LockClassKeys
> > rust: lockdep: Use Pin for all LockClassKey usages
> >
> > Randy Dunlap (1):
> > locking/rtmutex: Use struct keyword in kernel-doc comment
> >
> > Waiman Long (5):
> > locking/semaphore: Use wake_q to wake up processes outside lock
> > critical section
> > locking/lock_events: Add locking events for rtmutex slow paths
> > locking/lock_events: Add locking events for lockdep
> > locking/lockdep: Disable KASAN instrumentation of lockdep.c
> > locking/lockdep: Add kasan_check_byte() check in lock_acquire()
>
> Thanks Boqun!
>
Thanks.
> I've applied these 3 patches to the tip:locking/urgent tree:
>
> locking/semaphore: Use wake_q to wake up processes outside lock critical section
> locking/rtmutex: Use the 'struct' keyword in kernel-doc comment
> rust: lockdep: Remove support for dynamically allocated LockClassKeys
>
> As a general rule, if a patch is marked Cc: stable, it must also be
> applied to current upstream.
>
Do you prefer a separate pull request for the future? I can send one for
urgent and one for locking/core.
> I have applied the others to tip:locking/core:
>
> locking/lock_events: Add locking events for rtmutex slow pathsa94d32446ab5 locking/lock_events: Add locking events for lockdep
> locking/lockdep: Disable KASAN instrumentation of lockdep.c
> locking/lockdep: Add kasan_check_byte() check in lock_acquire()
> rust: sync: Add accessor for the lock behind a given guard
> rust: sync: lock: Add an example for Guard:: Lock_ref()
> rust: sync: condvar: Add wait_interruptible_freezable()
> rust: lockdep: Use Pin for all LockClassKey usages
>
> I cleaned up changelogs where necessary - for example we generally
> don't include printk timestamps in changelogs, unless it's relevant,
Got it, I will avoid them in the future.
> plus there were a number of typos and grammar mistakes left in some of
> the changelogs.
>
Will take a look at your updates and keep working on improve them,
thanks!
Regards,
Boqun
> Thanks,
>
> Ingo
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15
2025-03-08 0:04 ` Boqun Feng
@ 2025-03-08 0:11 ` Ingo Molnar
2025-03-08 0:11 ` Boqun Feng
0 siblings, 1 reply; 14+ messages in thread
From: Ingo Molnar @ 2025-03-08 0:11 UTC (permalink / raw)
To: Boqun Feng
Cc: Peter Zijlstra, Will Deacon, Waiman Long, linux-kernel,
Miguel Ojeda, Alex Gaynor, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
open list:RUST:Keyword:b(?i:rust)b
* Boqun Feng <boqun.feng@gmail.com> wrote:
> On Sat, Mar 08, 2025 at 01:01:45AM +0100, Ingo Molnar wrote:
> >
> > * Boqun Feng <boqun.feng@gmail.com> wrote:
> >
> > > Hi Ingo & Peter,
> > >
> > > As discussed, I'm resending the pull request for lockdep and Rust
> > > locking for v6.15 in the format of email patches. I dropped one patch
> > > and will postpone it for v6.16 because of a bug [1], and I think the fix
> > > [2] needs more reviews.
> > >
> > > [1]: https://lore.kernel.org/lkml/20250306122413.GBZ8mT7Z61Tmgnh5Y9@fat_crate.local/
> > > [2]: https://lore.kernel.org/lkml/Z8t8imzJVhWyDvhC@boqun-archlinux/
> > >
> > > Regards,
> > > Boqun
> > >
> > > Alice Ryhl (2):
> > > rust: sync: Add accessor for the lock behind a given guard
> > > rust: sync: condvar: Add wait_interruptible_freezable()
> > >
> > > Boqun Feng (1):
> > > rust: sync: lock: Add an example for Guard::lock_ref()
> > >
> > > Mitchell Levy (2):
> > > rust: lockdep: Remove support for dynamically allocated LockClassKeys
> > > rust: lockdep: Use Pin for all LockClassKey usages
> > >
> > > Randy Dunlap (1):
> > > locking/rtmutex: Use struct keyword in kernel-doc comment
> > >
> > > Waiman Long (5):
> > > locking/semaphore: Use wake_q to wake up processes outside lock
> > > critical section
> > > locking/lock_events: Add locking events for rtmutex slow paths
> > > locking/lock_events: Add locking events for lockdep
> > > locking/lockdep: Disable KASAN instrumentation of lockdep.c
> > > locking/lockdep: Add kasan_check_byte() check in lock_acquire()
> >
> > Thanks Boqun!
> >
>
> Thanks.
>
> > I've applied these 3 patches to the tip:locking/urgent tree:
> >
> > locking/semaphore: Use wake_q to wake up processes outside lock critical section
> > locking/rtmutex: Use the 'struct' keyword in kernel-doc comment
> > rust: lockdep: Remove support for dynamically allocated LockClassKeys
> >
> > As a general rule, if a patch is marked Cc: stable, it must also be
> > applied to current upstream.
> >
>
> Do you prefer a separate pull request for the future? I can send one for
> urgent and one for locking/core.
One tree is fine - maybe indicate which ones are urgent material and
keep them at the head of the tree?
Thanks,
Ingo
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15
2025-03-08 0:11 ` Ingo Molnar
@ 2025-03-08 0:11 ` Boqun Feng
0 siblings, 0 replies; 14+ messages in thread
From: Boqun Feng @ 2025-03-08 0:11 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, Will Deacon, Waiman Long, linux-kernel,
Miguel Ojeda, Alex Gaynor, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
open list:RUST:Keyword:b(?i:rust)b
On Sat, Mar 08, 2025 at 01:11:36AM +0100, Ingo Molnar wrote:
[...]
> > > I've applied these 3 patches to the tip:locking/urgent tree:
> > >
> > > locking/semaphore: Use wake_q to wake up processes outside lock critical section
> > > locking/rtmutex: Use the 'struct' keyword in kernel-doc comment
> > > rust: lockdep: Remove support for dynamically allocated LockClassKeys
> > >
> > > As a general rule, if a patch is marked Cc: stable, it must also be
> > > applied to current upstream.
> > >
> >
> > Do you prefer a separate pull request for the future? I can send one for
> > urgent and one for locking/core.
>
> One tree is fine - maybe indicate which ones are urgent material and
> keep them at the head of the tree?
>
Sounds good to me, will do.
Regards,
Boqun
> Thanks,
>
> Ingo
^ permalink raw reply [flat|nested] 14+ messages in thread