rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 01/13] rust: sync: introduce `LockClassKey`
@ 2023-04-05 17:50 Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 02/13] rust: sync: introduce `Lock` and `Guard` Wedson Almeida Filho
                   ` (13 more replies)
  0 siblings, 14 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:50 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

From: Wedson Almeida Filho <walmeida@microsoft.com>

It is a wrapper around C's `lock_class_key`, which is used by the
synchronisation primitives that are checked with lockdep. This is in
preparation for introducing Rust abstractions for these primitives.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Co-developed-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: Fixed a typo in comment

 rust/kernel/sync.rs | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 33da23e3076d..84a4b560828c 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -5,6 +5,51 @@
 //! 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::types::Opaque;
+
 mod arc;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
+
+/// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
+#[repr(transparent)]
+pub struct LockClassKey(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 {
+    /// Creates a new lock class key.
+    pub const fn new() -> Self {
+        Self(Opaque::uninit())
+    }
+
+    #[allow(dead_code)]
+    pub(crate) fn as_ptr(&self) -> *mut bindings::lock_class_key {
+        self.0.get()
+    }
+}
+
+/// 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();
+        &CLASS
+    }};
+}
+
+/// Returns the given string, if one is provided, otherwise generates one based on the source code
+/// location.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! optional_name {
+    () => {
+        $crate::c_str!(core::concat!(core::file!(), ":", core::line!()))
+    };
+    ($name:literal) => {
+        $crate::c_str!($name)
+    };
+}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 02/13] rust: sync: introduce `Lock` and `Guard`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 03/13] rust: lock: introduce `Mutex` Wedson Almeida Filho
                   ` (12 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

From: Wedson Almeida Filho <walmeida@microsoft.com>

They are generic Rust implementations of a lock and a lock guard that
contain code that is common to all locks. Different backends will be
introduced in subsequent commits.

Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/kernel/sync.rs      |   2 +-
 rust/kernel/sync/lock.rs | 160 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 161 insertions(+), 1 deletion(-)
 create mode 100644 rust/kernel/sync/lock.rs

diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 84a4b560828c..bf088b324af4 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -8,6 +8,7 @@
 use crate::types::Opaque;
 
 mod arc;
+pub mod lock;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 
@@ -25,7 +26,6 @@ impl LockClassKey {
         Self(Opaque::uninit())
     }
 
-    #[allow(dead_code)]
     pub(crate) fn as_ptr(&self) -> *mut bindings::lock_class_key {
         self.0.get()
     }
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
new file mode 100644
index 000000000000..f5614bed2a78
--- /dev/null
+++ b/rust/kernel/sync/lock.rs
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Generic kernel lock and guard.
+//!
+//! It contains a generic Rust lock and guard that allow for different backends (e.g., mutexes,
+//! spinlocks, raw spinlocks) to be provided with minimal effort.
+
+use super::LockClassKey;
+use crate::{bindings, init::PinInit, pin_init, str::CStr, types::Opaque};
+use core::{cell::UnsafeCell, marker::PhantomData, marker::PhantomPinned};
+use macros::pin_data;
+
+/// The "backend" of a lock.
+///
+/// It is the actual implementation of the lock, without the need to repeat patterns used in all
+/// locks.
+///
+/// # Safety
+///
+/// - Implementers must ensure that only one thread/CPU may access the protected data once the lock
+/// is owned, that is, between calls to `lock` and `unlock`.
+pub unsafe trait Backend {
+    /// The state required by the lock.
+    type State;
+
+    /// The state required to be kept between lock and unlock.
+    type GuardState;
+
+    /// Initialises the lock.
+    ///
+    /// # Safety
+    ///
+    /// `ptr` must be valid for write for the duration of the call, while `name` and `key` must
+    /// remain valid for read indefinitely.
+    unsafe fn init(
+        ptr: *mut Self::State,
+        name: *const core::ffi::c_char,
+        key: *mut bindings::lock_class_key,
+    );
+
+    /// Acquires the lock, making the caller its owner.
+    ///
+    /// # Safety
+    ///
+    /// Callers must ensure that [`Backend::init`] has been previously called.
+    #[must_use]
+    unsafe fn lock(ptr: *mut Self::State) -> Self::GuardState;
+
+    /// Releases the lock, giving up its ownership.
+    ///
+    /// # Safety
+    ///
+    /// It must only be called by the current owner of the lock.
+    unsafe fn unlock(ptr: *mut Self::State, guard_state: &Self::GuardState);
+}
+
+/// A mutual exclusion primitive.
+///
+/// Exposes one of the kernel locking primitives. Which one is exposed depends on the lock banckend
+/// specified as the generic parameter `T`.
+#[pin_data]
+pub struct Lock<T: ?Sized, B: Backend> {
+    /// The kernel lock object.
+    #[pin]
+    state: Opaque<B::State>,
+
+    /// Some locks are known to be self-referential (e.g., mutexes), while others are architecture
+    /// or config defined (e.g., spinlocks). So we conservatively require them to be pinned in case
+    /// some architecture uses self-references now or in the future.
+    #[pin]
+    _pin: PhantomPinned,
+
+    /// The data protected by the lock.
+    data: UnsafeCell<T>,
+}
+
+// SAFETY: `Lock` can be transferred across thread boundaries iff the data it protects can.
+unsafe impl<T: ?Sized + Send, B: Backend> Send for Lock<T, B> {}
+
+// SAFETY: `Lock` serialises the interior mutability it provides, so it is `Sync` as long as the
+// data it protects is `Send`.
+unsafe impl<T: ?Sized + Send, B: Backend> Sync for Lock<T, B> {}
+
+impl<T, B: Backend> Lock<T, B> {
+    /// Constructs a new lock initialiser.
+    #[allow(clippy::new_ret_no_self)]
+    pub fn new(t: T, name: &'static CStr, key: &'static LockClassKey) -> impl PinInit<Self> {
+        pin_init!(Self {
+            data: UnsafeCell::new(t),
+            _pin: PhantomPinned,
+            // SAFETY: `B::init` initialises the lock state, and both `name` and `key` have static
+            // lifetimes so they live indefinitely.
+            state <- unsafe { Opaque::manual_init2(B::init, name.as_char_ptr(), key.as_ptr()) },
+        })
+    }
+}
+
+impl<T: ?Sized, B: Backend> Lock<T, B> {
+    /// Acquires the lock and gives the caller access to the data protected by it.
+    pub fn lock(&self) -> Guard<'_, T, B> {
+        // SAFETY: The constructor of the type calls `init`, so the existence of the object proves
+        // that `init` was called.
+        let state = unsafe { B::lock(self.state.get()) };
+        // SAFETY: The lock was just acquired.
+        unsafe { Guard::new(self, state) }
+    }
+}
+
+/// A lock guard.
+///
+/// Allows mutual exclusion primitives that implement the `Backend` trait to automatically unlock
+/// when a guard goes out of scope. It also provides a safe and convenient way to access the data
+/// protected by the lock.
+#[must_use = "the lock unlocks immediately when the guard is unused"]
+pub struct Guard<'a, T: ?Sized, B: Backend> {
+    pub(crate) lock: &'a Lock<T, B>,
+    pub(crate) state: B::GuardState,
+    _not_send: PhantomData<*mut ()>,
+}
+
+// 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> core::ops::Deref for Guard<'_, T, B> {
+    type Target = T;
+
+    fn deref(&self) -> &Self::Target {
+        // SAFETY: The caller owns the lock, so it is safe to deref the protected data.
+        unsafe { &*self.lock.data.get() }
+    }
+}
+
+impl<T: ?Sized, B: Backend> core::ops::DerefMut for Guard<'_, T, B> {
+    fn deref_mut(&mut self) -> &mut Self::Target {
+        // SAFETY: The caller owns the lock, so it is safe to deref the protected data.
+        unsafe { &mut *self.lock.data.get() }
+    }
+}
+
+impl<T: ?Sized, B: Backend> Drop for Guard<'_, T, B> {
+    fn drop(&mut self) {
+        // SAFETY: The caller owns the lock, so it is safe to unlock it.
+        unsafe { B::unlock(self.lock.state.get(), &self.state) };
+    }
+}
+
+impl<'a, T: ?Sized, B: Backend> Guard<'a, T, B> {
+    /// Constructs a new immutable lock guard.
+    ///
+    /// # Safety
+    ///
+    /// The caller must ensure that it owns the lock.
+    pub(crate) unsafe fn new(lock: &'a Lock<T, B>, state: B::GuardState) -> Self {
+        Self {
+            lock,
+            state,
+            _not_send: PhantomData,
+        }
+    }
+}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 02/13] rust: sync: introduce `Lock` and `Guard` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 18:03   ` Greg KH
  2023-04-05 17:51 ` [PATCH v2 04/13] locking/spinlock: introduce spin_lock_init_with_key Wedson Almeida Filho
                   ` (11 subsequent siblings)
  13 siblings, 1 reply; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

From: Wedson Almeida Filho <walmeida@microsoft.com>

This is the `struct mutex` lock backend and allows Rust code to use the
kernel mutex idiomatically.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/helpers.c                 |   7 ++
 rust/kernel/sync.rs            |   1 +
 rust/kernel/sync/lock.rs       |   2 +
 rust/kernel/sync/lock/mutex.rs | 118 +++++++++++++++++++++++++++++++++
 4 files changed, 128 insertions(+)
 create mode 100644 rust/kernel/sync/lock/mutex.rs

diff --git a/rust/helpers.c b/rust/helpers.c
index 09a4d93f9d62..3010a2ec26e2 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -21,6 +21,7 @@
 #include <linux/bug.h>
 #include <linux/build_bug.h>
 #include <linux/refcount.h>
+#include <linux/mutex.h>
 
 __noreturn void rust_helper_BUG(void)
 {
@@ -28,6 +29,12 @@ __noreturn void rust_helper_BUG(void)
 }
 EXPORT_SYMBOL_GPL(rust_helper_BUG);
 
+void rust_helper_mutex_lock(struct mutex *lock)
+{
+	mutex_lock(lock);
+}
+EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
+
 refcount_t rust_helper_REFCOUNT_INIT(int n)
 {
 	return (refcount_t)REFCOUNT_INIT(n);
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index bf088b324af4..9ff116b2eebe 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -11,6 +11,7 @@ mod arc;
 pub mod lock;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
+pub use lock::mutex::Mutex;
 
 /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
 #[repr(transparent)]
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index f5614bed2a78..cec1d68bab86 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -10,6 +10,8 @@ use crate::{bindings, init::PinInit, pin_init, str::CStr, types::Opaque};
 use core::{cell::UnsafeCell, marker::PhantomData, marker::PhantomPinned};
 use macros::pin_data;
 
+pub mod mutex;
+
 /// The "backend" of a lock.
 ///
 /// It is the actual implementation of the lock, without the need to repeat patterns used in all
diff --git a/rust/kernel/sync/lock/mutex.rs b/rust/kernel/sync/lock/mutex.rs
new file mode 100644
index 000000000000..923472f04af4
--- /dev/null
+++ b/rust/kernel/sync/lock/mutex.rs
@@ -0,0 +1,118 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! A kernel mutex.
+//!
+//! This module allows Rust code to use the kernel's `struct mutex`.
+
+use crate::bindings;
+
+/// Creates a [`Mutex`] 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_mutex {
+    ($inner:expr $(, $name:literal)? $(,)?) => {
+        $crate::sync::Mutex::new(
+            $inner, $crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+
+/// A mutual exclusion primitive.
+///
+/// Exposes the kernel's [`struct mutex`]. When multiple threads attempt to lock the same mutex,
+/// only one at a time is allowed to progress, the others will block (sleep) until the mutex is
+/// unlocked, at which point another thread will be allowed to wake up and make progress.
+///
+/// Since it may block, [`Mutex`] needs to be used with care in atomic contexts.
+///
+/// Instances of [`Mutex`] need a lock class and to be pinned. The recommended way to create such
+/// instances is with the [`pin_init`](crate::pin_init) and [`new_mutex`] macros.
+///
+/// # Examples
+///
+/// The following example shows how to declare, allocate and initialise a struct (`Example`) that
+/// contains an inner struct (`Inner`) that is protected by a mutex.
+///
+/// ```
+/// use kernel::{init::InPlaceInit, init::PinInit, new_mutex, pin_init, sync::Mutex};
+///
+/// struct Inner {
+///     a: u32,
+///     b: u32,
+/// }
+///
+/// #[pin_data]
+/// struct Example {
+///     c: u32,
+///     #[pin]
+///     d: Mutex<Inner>,
+/// }
+///
+/// impl Example {
+///     fn new() -> impl PinInit<Self> {
+///         pin_init!(Self {
+///             c: 10,
+///             d <- new_mutex!(Inner { a: 20, b: 30 }),
+///         })
+///     }
+/// }
+///
+/// // Allocate a boxed `Example`.
+/// let e = Box::pin_init(Example::new())?;
+/// assert_eq!(e.c, 10);
+/// assert_eq!(e.d.lock().a, 20);
+/// assert_eq!(e.d.lock().b, 30);
+/// ```
+///
+/// The following example shows how to use interior mutability to modify the contents of a struct
+/// protected by a mutex despite only having a shared reference:
+///
+/// ```
+/// use kernel::sync::Mutex;
+///
+/// struct Example {
+///     a: u32,
+///     b: u32,
+/// }
+///
+/// fn example(m: &Mutex<Example>) {
+///     let mut guard = m.lock();
+///     guard.a += 10;
+///     guard.b += 20;
+/// }
+/// ```
+///
+/// [`struct mutex`]: ../../../../include/linux/mutex.h
+pub type Mutex<T> = super::Lock<T, MutexBackend>;
+
+/// A kernel `struct mutex` lock backend.
+pub struct MutexBackend;
+
+// SAFETY: The underlying kernel `struct mutex` object ensures mutual exclusion.
+unsafe impl super::Backend for MutexBackend {
+    type State = bindings::mutex;
+    type GuardState = ();
+
+    unsafe fn init(
+        ptr: *mut Self::State,
+        name: *const core::ffi::c_char,
+        key: *mut bindings::lock_class_key,
+    ) {
+        // SAFETY: The safety requirements ensure that `ptr` is valid for writes, and `name` and
+        // `key` are valid for read indefinitely.
+        unsafe { bindings::__mutex_init(ptr, name, key) }
+    }
+
+    unsafe fn lock(ptr: *mut Self::State) -> Self::GuardState {
+        // SAFETY: The safety requirements of this function ensure that `ptr` points to valid
+        // memory, and that it has been initialised before.
+        unsafe { bindings::mutex_lock(ptr) };
+    }
+
+    unsafe fn unlock(ptr: *mut Self::State, _guard_state: &Self::GuardState) {
+        // SAFETY: The safety requirements of this function ensure that `ptr` is valid and that the
+        // caller is the owner of the mutex.
+        unsafe { bindings::mutex_unlock(ptr) };
+    }
+}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 04/13] locking/spinlock: introduce spin_lock_init_with_key
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 02/13] rust: sync: introduce `Lock` and `Guard` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 03/13] rust: lock: introduce `Mutex` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 05/13] rust: lock: introduce `SpinLock` Wedson Almeida Filho
                   ` (10 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

From: Wedson Almeida Filho <walmeida@microsoft.com>

Rust cannot call C macros, so it has its own macro to create a new lock
class when a spin lock is initialised. This new function allows Rust
code to pass the lock class it generates to the C implementation.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 include/linux/spinlock.h | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index be48f1cb1878..cdc92d095133 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -327,12 +327,17 @@ static __always_inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
 
 #ifdef CONFIG_DEBUG_SPINLOCK
 
+static inline void spin_lock_init_with_key(spinlock_t *lock, const char *name,
+					   struct lock_class_key *key)
+{
+	__raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG);
+}
+
 # define spin_lock_init(lock)					\
 do {								\
 	static struct lock_class_key __key;			\
 								\
-	__raw_spin_lock_init(spinlock_check(lock),		\
-			     #lock, &__key, LD_WAIT_CONFIG);	\
+	spin_lock_init_with_key(lock, #lock, &__key);		\
 } while (0)
 
 #else
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 05/13] rust: lock: introduce `SpinLock`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (2 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 04/13] locking/spinlock: introduce spin_lock_init_with_key Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 06/13] rust: lock: add support for `Lock::lock_irqsave` Wedson Almeida Filho
                   ` (9 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

From: Wedson Almeida Filho <walmeida@microsoft.com>

This is the `spinlock_t` lock backend and allows Rust code to use the
kernel spinlock idiomatically.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/helpers.c                    |  24 +++++++
 rust/kernel/sync.rs               |   2 +-
 rust/kernel/sync/lock.rs          |   1 +
 rust/kernel/sync/lock/spinlock.rs | 116 ++++++++++++++++++++++++++++++
 4 files changed, 142 insertions(+), 1 deletion(-)
 create mode 100644 rust/kernel/sync/lock/spinlock.rs

diff --git a/rust/helpers.c b/rust/helpers.c
index 3010a2ec26e2..05694e3f8f70 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -22,6 +22,7 @@
 #include <linux/build_bug.h>
 #include <linux/refcount.h>
 #include <linux/mutex.h>
+#include <linux/spinlock.h>
 
 __noreturn void rust_helper_BUG(void)
 {
@@ -35,6 +36,29 @@ void rust_helper_mutex_lock(struct mutex *lock)
 }
 EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
 
+void rust_helper___spin_lock_init(spinlock_t *lock, const char *name,
+				  struct lock_class_key *key)
+{
+#ifdef CONFIG_DEBUG_SPINLOCK
+	spin_lock_init_with_key(lock, name, key);
+#else
+	spin_lock_init(lock);
+#endif
+}
+EXPORT_SYMBOL_GPL(rust_helper___spin_lock_init);
+
+void rust_helper_spin_lock(spinlock_t *lock)
+{
+	spin_lock(lock);
+}
+EXPORT_SYMBOL_GPL(rust_helper_spin_lock);
+
+void rust_helper_spin_unlock(spinlock_t *lock)
+{
+	spin_unlock(lock);
+}
+EXPORT_SYMBOL_GPL(rust_helper_spin_unlock);
+
 refcount_t rust_helper_REFCOUNT_INIT(int n)
 {
 	return (refcount_t)REFCOUNT_INIT(n);
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 9ff116b2eebe..ed07437d7d55 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -11,7 +11,7 @@ mod arc;
 pub mod lock;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
-pub use lock::mutex::Mutex;
+pub use lock::{mutex::Mutex, spinlock::SpinLock};
 
 /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
 #[repr(transparent)]
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index cec1d68bab86..bca9af2a9a5a 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -11,6 +11,7 @@ use core::{cell::UnsafeCell, marker::PhantomData, marker::PhantomPinned};
 use macros::pin_data;
 
 pub mod mutex;
+pub mod spinlock;
 
 /// The "backend" of a lock.
 ///
diff --git a/rust/kernel/sync/lock/spinlock.rs b/rust/kernel/sync/lock/spinlock.rs
new file mode 100644
index 000000000000..a52d20fc9755
--- /dev/null
+++ b/rust/kernel/sync/lock/spinlock.rs
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! A kernel spinlock.
+//!
+//! This module allows Rust code to use the kernel's `spinlock_t`.
+
+use crate::bindings;
+
+/// Creates a [`SpinLock`] 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_spinlock {
+    ($inner:expr $(, $name:literal)? $(,)?) => {
+        $crate::sync::SpinLock::new(
+            $inner, $crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+
+/// A spinlock.
+///
+/// Exposes the kernel's [`spinlock_t`]. When multiple CPUs attempt to lock the same spinlock, only
+/// one at a time is allowed to progress, the others will block (spinning) until the spinlock is
+/// unlocked, at which point another CPU will be allowed to make progress.
+///
+/// Instances of [`SpinLock`] need a lock class and to be pinned. The recommended way to create such
+/// instances is with the [`pin_init`](crate::pin_init) and [`new_spinlock`] macros.
+///
+/// # Examples
+///
+/// The following example shows how to declare, allocate and initialise a struct (`Example`) that
+/// contains an inner struct (`Inner`) that is protected by a spinlock.
+///
+/// ```
+/// use kernel::{init::InPlaceInit, init::PinInit, new_spinlock, pin_init, sync::SpinLock};
+///
+/// struct Inner {
+///     a: u32,
+///     b: u32,
+/// }
+///
+/// #[pin_data]
+/// struct Example {
+///     c: u32,
+///     #[pin]
+///     d: SpinLock<Inner>,
+/// }
+///
+/// impl Example {
+///     fn new() -> impl PinInit<Self> {
+///         pin_init!(Self {
+///             c: 10,
+///             d <- new_spinlock!(Inner { a: 20, b: 30 }),
+///         })
+///     }
+/// }
+///
+/// // Allocate a boxed `Example`.
+/// let e = Box::pin_init(Example::new())?;
+/// assert_eq!(e.c, 10);
+/// assert_eq!(e.d.lock().a, 20);
+/// assert_eq!(e.d.lock().b, 30);
+/// ```
+///
+/// The following example shows how to use interior mutability to modify the contents of a struct
+/// protected by a spinlock despite only having a shared reference:
+///
+/// ```
+/// use kernel::sync::SpinLock;
+///
+/// struct Example {
+///     a: u32,
+///     b: u32,
+/// }
+///
+/// fn example(m: &SpinLock<Example>) {
+///     let mut guard = m.lock();
+///     guard.a += 10;
+///     guard.b += 20;
+/// }
+/// ```
+///
+/// [`spinlock_t`]: ../../../../include/linux/spinlock.h
+pub type SpinLock<T> = super::Lock<T, SpinLockBackend>;
+
+/// A kernel `spinlock_t` lock backend.
+pub struct SpinLockBackend;
+
+// SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion.
+unsafe impl super::Backend for SpinLockBackend {
+    type State = bindings::spinlock_t;
+    type GuardState = ();
+
+    unsafe fn init(
+        ptr: *mut Self::State,
+        name: *const core::ffi::c_char,
+        key: *mut bindings::lock_class_key,
+    ) {
+        // SAFETY: The safety requirements ensure that `ptr` is valid for writes, and `name` and
+        // `key` are valid for read indefinitely.
+        unsafe { bindings::__spin_lock_init(ptr, name, key) }
+    }
+
+    unsafe fn lock(ptr: *mut Self::State) -> Self::GuardState {
+        // SAFETY: The safety requirements of this function ensure that `ptr` points to valid
+        // memory, and that it has been initialised before.
+        unsafe { bindings::spin_lock(ptr) }
+    }
+
+    unsafe fn unlock(ptr: *mut Self::State, _guard_state: &Self::GuardState) {
+        // SAFETY: The safety requirements of this function ensure that `ptr` is valid and that the
+        // caller is the owner of the mutex.
+        unsafe { bindings::spin_unlock(ptr) }
+    }
+}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 06/13] rust: lock: add support for `Lock::lock_irqsave`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (3 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 05/13] rust: lock: introduce `SpinLock` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 07/13] rust: lock: implement `IrqSaveBackend` for `SpinLock` Wedson Almeida Filho
                   ` (8 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

From: Wedson Almeida Filho <walmeida@microsoft.com>

This allows locks like spinlocks and raw spinlocks to expose a
`lock_irqsave` variant in Rust that corresponds to the C version.

Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/kernel/sync/lock.rs | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index bca9af2a9a5a..491446c3a074 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -57,6 +57,29 @@ pub unsafe trait Backend {
     unsafe fn unlock(ptr: *mut Self::State, guard_state: &Self::GuardState);
 }
 
+/// The "backend" of a lock that supports the irq-save variant.
+///
+/// # Safety
+///
+/// The same requirements wrt mutual exclusion in [`Backend`] apply for acquiring the lock via
+/// [`IrqSaveBackend::lock_irqsave`].
+///
+/// Additionally, when [`IrqSaveBackend::lock_irqsave`] is used to acquire the lock, implementers
+/// must disable interrupts on lock, and restore interrupt state on unlock. Implementers may use
+/// [`Backend::GuardState`] to store state needed to keep track of the interrupt state.
+pub unsafe trait IrqSaveBackend: Backend {
+    /// Acquires the lock, making the caller its owner.
+    ///
+    /// Before acquiring the lock, it disables interrupts, and returns the previous interrupt state
+    /// as its guard state so that the guard can restore it when it is dropped.
+    ///
+    /// # Safety
+    ///
+    /// Callers must ensure that [`Backend::init`] has been previously called.
+    #[must_use]
+    unsafe fn lock_irqsave(ptr: *mut Self::State) -> Self::GuardState;
+}
+
 /// A mutual exclusion primitive.
 ///
 /// Exposes one of the kernel locking primitives. Which one is exposed depends on the lock banckend
@@ -109,6 +132,21 @@ impl<T: ?Sized, B: Backend> Lock<T, B> {
     }
 }
 
+impl<T: ?Sized, B: IrqSaveBackend> Lock<T, B> {
+    /// Acquires the lock and gives the caller access to the data protected by it.
+    ///
+    /// Before acquiring the lock, it disables interrupts. When the guard is dropped, the interrupt
+    /// state (either enabled or disabled) is restored to its state before
+    /// [`lock_irqsave`](Self::lock_irqsave) was called.
+    pub fn lock_irqsave(&self) -> Guard<'_, T, B> {
+        // SAFETY: The constructor of the type calls `init`, so the existence of the object proves
+        // that `init` was called.
+        let state = unsafe { B::lock_irqsave(self.state.get()) };
+        // SAFETY: The lock was just acquired.
+        unsafe { Guard::new(self, state) }
+    }
+}
+
 /// A lock guard.
 ///
 /// Allows mutual exclusion primitives that implement the `Backend` trait to automatically unlock
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 07/13] rust: lock: implement `IrqSaveBackend` for `SpinLock`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (4 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 06/13] rust: lock: add support for `Lock::lock_irqsave` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 08/13] rust: introduce `ARef` Wedson Almeida Filho
                   ` (7 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

From: Wedson Almeida Filho <walmeida@microsoft.com>

This allows Rust code to use the `lock_irqsave` variant of spinlocks.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/helpers.c                    | 16 +++++++++++++
 rust/kernel/sync/lock/spinlock.rs | 38 ++++++++++++++++++++++++++-----
 2 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/rust/helpers.c b/rust/helpers.c
index 05694e3f8f70..e42f5b446f92 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -59,6 +59,22 @@ void rust_helper_spin_unlock(spinlock_t *lock)
 }
 EXPORT_SYMBOL_GPL(rust_helper_spin_unlock);
 
+unsigned long rust_helper_spin_lock_irqsave(spinlock_t *lock)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(lock, flags);
+
+	return flags;
+}
+EXPORT_SYMBOL_GPL(rust_helper_spin_lock_irqsave);
+
+void rust_helper_spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
+{
+	spin_unlock_irqrestore(lock, flags);
+}
+EXPORT_SYMBOL_GPL(rust_helper_spin_unlock_irqrestore);
+
 refcount_t rust_helper_REFCOUNT_INIT(int n)
 {
 	return (refcount_t)REFCOUNT_INIT(n);
diff --git a/rust/kernel/sync/lock/spinlock.rs b/rust/kernel/sync/lock/spinlock.rs
index a52d20fc9755..34dec09a97c0 100644
--- a/rust/kernel/sync/lock/spinlock.rs
+++ b/rust/kernel/sync/lock/spinlock.rs
@@ -61,6 +61,8 @@ macro_rules! new_spinlock {
 /// assert_eq!(e.c, 10);
 /// assert_eq!(e.d.lock().a, 20);
 /// assert_eq!(e.d.lock().b, 30);
+/// assert_eq!(e.d.lock_irqsave().a, 20);
+/// assert_eq!(e.d.lock_irqsave().b, 30);
 /// ```
 ///
 /// The following example shows how to use interior mutability to modify the contents of a struct
@@ -79,6 +81,12 @@ macro_rules! new_spinlock {
 ///     guard.a += 10;
 ///     guard.b += 20;
 /// }
+///
+/// fn example2(m: &SpinLock<Example>) {
+///     let mut guard = m.lock_irqsave();
+///     guard.a += 10;
+///     guard.b += 20;
+/// }
 /// ```
 ///
 /// [`spinlock_t`]: ../../../../include/linux/spinlock.h
@@ -90,7 +98,7 @@ pub struct SpinLockBackend;
 // SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion.
 unsafe impl super::Backend for SpinLockBackend {
     type State = bindings::spinlock_t;
-    type GuardState = ();
+    type GuardState = Option<core::ffi::c_ulong>;
 
     unsafe fn init(
         ptr: *mut Self::State,
@@ -105,12 +113,30 @@ unsafe impl super::Backend for SpinLockBackend {
     unsafe fn lock(ptr: *mut Self::State) -> Self::GuardState {
         // SAFETY: The safety requirements of this function ensure that `ptr` points to valid
         // memory, and that it has been initialised before.
-        unsafe { bindings::spin_lock(ptr) }
+        unsafe { bindings::spin_lock(ptr) };
+        None
     }
 
-    unsafe fn unlock(ptr: *mut Self::State, _guard_state: &Self::GuardState) {
-        // SAFETY: The safety requirements of this function ensure that `ptr` is valid and that the
-        // caller is the owner of the mutex.
-        unsafe { bindings::spin_unlock(ptr) }
+    unsafe fn unlock(ptr: *mut Self::State, guard_state: &Self::GuardState) {
+        match guard_state {
+            // SAFETY: The safety requirements of this function ensure that `ptr` is valid and that
+            // the caller is the owner of the mutex.
+            Some(flags) => unsafe { bindings::spin_unlock_irqrestore(ptr, *flags) },
+            // SAFETY: The safety requirements of this function ensure that `ptr` is valid and that
+            // the caller is the owner of the mutex.
+            None => unsafe { bindings::spin_unlock(ptr) },
+        }
+    }
+}
+
+// SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion. We use the `irqsave`
+// variant of the C lock acquisition functions to disable interrupts and retrieve the original
+// interrupt state, and the `irqrestore` variant of the lock release functions to restore the state
+// in `unlock` -- we use the guard context to determine which method was used to acquire the lock.
+unsafe impl super::IrqSaveBackend for SpinLockBackend {
+    unsafe fn lock_irqsave(ptr: *mut Self::State) -> Self::GuardState {
+        // SAFETY: The safety requirements of this function ensure that `ptr` points to valid
+        // memory, and that it has been initialised before.
+        Some(unsafe { bindings::spin_lock_irqsave(ptr) })
     }
 }
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 08/13] rust: introduce `ARef`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (5 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 07/13] rust: lock: implement `IrqSaveBackend` for `SpinLock` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-07 21:59   ` Benno Lossin
  2023-04-05 17:51 ` [PATCH v2 09/13] rust: add basic `Task` Wedson Almeida Filho
                   ` (6 subsequent siblings)
  13 siblings, 1 reply; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

From: Wedson Almeida Filho <walmeida@microsoft.com>

This is an owned reference to an object that is always ref-counted. This
is meant to be used in wrappers for C types that have their own ref
counting functions, for example, tasks, files, inodes, dentries, etc.

Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/kernel/types.rs | 107 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)

diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
index dbfae9bb97ce..b071730253c7 100644
--- a/rust/kernel/types.rs
+++ b/rust/kernel/types.rs
@@ -6,8 +6,10 @@ use crate::init::{self, PinInit};
 use alloc::boxed::Box;
 use core::{
     cell::UnsafeCell,
+    marker::PhantomData,
     mem::MaybeUninit,
     ops::{Deref, DerefMut},
+    ptr::NonNull,
 };
 
 /// Used to transfer ownership to and from foreign (non-Rust) languages.
@@ -295,6 +297,111 @@ opaque_init_funcs! {
     "Rust" manual_init4(arg1: A1, arg2: A2, arg3: A3, arg4: A4);
 }
 
+/// Types that are _always_ reference counted.
+///
+/// It allows such types to define their own custom ref increment and decrement functions.
+/// Additionally, it allows users to convert from a shared reference `&T` to an owned reference
+/// [`ARef<T>`].
+///
+/// This is usually implemented by wrappers to existing structures on the C side of the code. For
+/// Rust code, the recommendation is to use [`Arc`](crate::sync::Arc) to create reference-counted
+/// instances of a type.
+///
+/// # Safety
+///
+/// Implementers must ensure that increments to the reference count keep the object alive in memory
+/// at least until matching decrements are performed.
+///
+/// Implementers must also ensure that all instances are reference-counted. (Otherwise they
+/// won't be able to honour the requirement that [`AlwaysRefCounted::inc_ref`] keep the object
+/// alive.)
+pub unsafe trait AlwaysRefCounted {
+    /// Increments the reference count on the object.
+    fn inc_ref(&self);
+
+    /// Decrements the reference count on the object.
+    ///
+    /// Frees the object when the count reaches zero.
+    ///
+    /// # Safety
+    ///
+    /// Callers must ensure that there was a previous matching increment to the reference count,
+    /// and that the object is no longer used after its reference count is decremented (as it may
+    /// result in the object being freed), unless the caller owns another increment on the refcount
+    /// (e.g., it calls [`AlwaysRefCounted::inc_ref`] twice, then calls
+    /// [`AlwaysRefCounted::dec_ref`] once).
+    unsafe fn dec_ref(obj: NonNull<Self>);
+}
+
+/// An owned reference to an always-reference-counted object.
+///
+/// The object's reference count is automatically decremented when an instance of [`ARef`] is
+/// dropped. It is also automatically incremented when a new instance is created via
+/// [`ARef::clone`].
+///
+/// # Invariants
+///
+/// The pointer stored in `ptr` is non-null and valid for the lifetime of the [`ARef`] instance. In
+/// particular, the [`ARef`] instance owns an increment on the underlying object's reference count.
+pub struct ARef<T: AlwaysRefCounted> {
+    ptr: NonNull<T>,
+    _p: PhantomData<T>,
+}
+
+impl<T: AlwaysRefCounted> ARef<T> {
+    /// Creates a new instance of [`ARef`].
+    ///
+    /// It takes over an increment of the reference count on the underlying object.
+    ///
+    /// # Safety
+    ///
+    /// Callers must ensure that the reference count was incremented at least once, and that they
+    /// are properly relinquishing one increment. That is, if there is only one increment, callers
+    /// must not use the underlying object anymore -- it is only safe to do so via the newly
+    /// created [`ARef`].
+    pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
+        // INVARIANT: The safety requirements guarantee that the new instance now owns the
+        // increment on the refcount.
+        Self {
+            ptr,
+            _p: PhantomData,
+        }
+    }
+}
+
+impl<T: AlwaysRefCounted> Clone for ARef<T> {
+    fn clone(&self) -> Self {
+        self.inc_ref();
+        // SAFETY: We just incremented the refcount above.
+        unsafe { Self::from_raw(self.ptr) }
+    }
+}
+
+impl<T: AlwaysRefCounted> Deref for ARef<T> {
+    type Target = T;
+
+    fn deref(&self) -> &Self::Target {
+        // SAFETY: The type invariants guarantee that the object is valid.
+        unsafe { self.ptr.as_ref() }
+    }
+}
+
+impl<T: AlwaysRefCounted> From<&T> for ARef<T> {
+    fn from(b: &T) -> Self {
+        b.inc_ref();
+        // SAFETY: We just incremented the refcount above.
+        unsafe { Self::from_raw(NonNull::from(b)) }
+    }
+}
+
+impl<T: AlwaysRefCounted> Drop for ARef<T> {
+    fn drop(&mut self) {
+        // SAFETY: The type invariants guarantee that the `ARef` owns the reference we're about to
+        // decrement.
+        unsafe { T::dec_ref(self.ptr) };
+    }
+}
+
 /// A sum type that always holds either a value of type `L` or `R`.
 pub enum Either<L, R> {
     /// Constructs an instance of [`Either`] containing a value of type `L`.
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 09/13] rust: add basic `Task`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (6 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 08/13] rust: introduce `ARef` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 10/13] rust: introduce `current` Wedson Almeida Filho
                   ` (5 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Ingo Molnar, Peter Zijlstra

From: Wedson Almeida Filho <walmeida@microsoft.com>

It is an abstraction for C's `struct task_struct`. It implements
`AlwaysRefCounted`, so the refcount of the wrapped object is managed
safely on the Rust side.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/bindings/bindings_helper.h |  1 +
 rust/helpers.c                  | 19 +++++++++
 rust/kernel/lib.rs              |  1 +
 rust/kernel/task.rs             | 71 +++++++++++++++++++++++++++++++++
 4 files changed, 92 insertions(+)
 create mode 100644 rust/kernel/task.rs

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 75d85bd6c592..03656a44a83f 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -8,6 +8,7 @@
 
 #include <linux/slab.h>
 #include <linux/refcount.h>
+#include <linux/sched.h>
 
 /* `bindgen` gets confused at certain things. */
 const gfp_t BINDINGS_GFP_KERNEL = GFP_KERNEL;
diff --git a/rust/helpers.c b/rust/helpers.c
index e42f5b446f92..58a194042c86 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -23,6 +23,7 @@
 #include <linux/refcount.h>
 #include <linux/mutex.h>
 #include <linux/spinlock.h>
+#include <linux/sched/signal.h>
 
 __noreturn void rust_helper_BUG(void)
 {
@@ -75,6 +76,12 @@ void rust_helper_spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
 }
 EXPORT_SYMBOL_GPL(rust_helper_spin_unlock_irqrestore);
 
+int rust_helper_signal_pending(struct task_struct *t)
+{
+	return signal_pending(t);
+}
+EXPORT_SYMBOL_GPL(rust_helper_signal_pending);
+
 refcount_t rust_helper_REFCOUNT_INIT(int n)
 {
 	return (refcount_t)REFCOUNT_INIT(n);
@@ -93,6 +100,18 @@ bool rust_helper_refcount_dec_and_test(refcount_t *r)
 }
 EXPORT_SYMBOL_GPL(rust_helper_refcount_dec_and_test);
 
+void rust_helper_get_task_struct(struct task_struct *t)
+{
+	get_task_struct(t);
+}
+EXPORT_SYMBOL_GPL(rust_helper_get_task_struct);
+
+void rust_helper_put_task_struct(struct task_struct *t)
+{
+	put_task_struct(t);
+}
+EXPORT_SYMBOL_GPL(rust_helper_put_task_struct);
+
 /*
  * We use `bindgen`'s `--size_t-is-usize` option to bind the C `size_t` type
  * as the Rust `usize` type, so we can use it in contexts where Rust
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index d9df77132fa2..4e1d5ba2e241 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -43,6 +43,7 @@ mod static_assert;
 pub mod std_vendor;
 pub mod str;
 pub mod sync;
+pub mod task;
 pub mod types;
 
 #[doc(hidden)]
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
new file mode 100644
index 000000000000..8d7a8222990f
--- /dev/null
+++ b/rust/kernel/task.rs
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Tasks (threads and processes).
+//!
+//! C header: [`include/linux/sched.h`](../../../../include/linux/sched.h).
+
+use crate::bindings;
+use core::{cell::UnsafeCell, ptr};
+
+/// Wraps the kernel's `struct task_struct`.
+///
+/// # Invariants
+///
+/// Instances of this type are always ref-counted, that is, a call to `get_task_struct` ensures
+/// that the allocation remains valid at least until the matching call to `put_task_struct`.
+#[repr(transparent)]
+pub struct Task(pub(crate) UnsafeCell<bindings::task_struct>);
+
+// SAFETY: It's OK to access `Task` through references from other threads because we're either
+// accessing properties that don't change (e.g., `pid`, `group_leader`) or that are properly
+// synchronised by C code (e.g., `signal_pending`).
+unsafe impl Sync for Task {}
+
+/// The type of process identifiers (PIDs).
+type Pid = bindings::pid_t;
+
+impl Task {
+    /// Returns the group leader of the given task.
+    pub fn group_leader(&self) -> &Task {
+        // SAFETY: By the type invariant, we know that `self.0` is valid.
+        let ptr = unsafe { *ptr::addr_of!((*self.0.get()).group_leader) };
+
+        // SAFETY: The lifetime of the returned task reference is tied to the lifetime of `self`,
+        // and given that a task has a reference to its group leader, we know it must be valid for
+        // the lifetime of the returned task reference.
+        unsafe { &*ptr.cast() }
+    }
+
+    /// Returns the PID of the given task.
+    pub fn pid(&self) -> Pid {
+        // SAFETY: By the type invariant, we know that `self.0` is valid.
+        unsafe { *ptr::addr_of!((*self.0.get()).pid) }
+    }
+
+    /// Determines whether the given task has pending signals.
+    pub fn signal_pending(&self) -> bool {
+        // SAFETY: By the type invariant, we know that `self.0` is valid.
+        unsafe { bindings::signal_pending(self.0.get()) != 0 }
+    }
+
+    /// Wakes up the task.
+    pub fn wake_up(&self) {
+        // SAFETY: By the type invariant, we know that `self.0.get()` is non-null and valid.
+        // And `wake_up_process` is safe to be called for any valid task, even if the task is
+        // running.
+        unsafe { bindings::wake_up_process(self.0.get()) };
+    }
+}
+
+// SAFETY: The type invariants guarantee that `Task` is always ref-counted.
+unsafe impl crate::types::AlwaysRefCounted for Task {
+    fn inc_ref(&self) {
+        // SAFETY: The existence of a shared reference means that the refcount is nonzero.
+        unsafe { bindings::get_task_struct(self.0.get()) };
+    }
+
+    unsafe fn dec_ref(obj: ptr::NonNull<Self>) {
+        // SAFETY: The safety requirements guarantee that the refcount is nonzero.
+        unsafe { bindings::put_task_struct(obj.cast().as_ptr()) }
+    }
+}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 10/13] rust: introduce `current`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (7 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 09/13] rust: add basic `Task` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-07 22:36   ` Benno Lossin
  2023-04-05 17:51 ` [PATCH v2 11/13] rust: lock: add `Guard::do_unlocked` Wedson Almeida Filho
                   ` (4 subsequent siblings)
  13 siblings, 1 reply; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Ingo Molnar, Peter Zijlstra

From: Wedson Almeida Filho <walmeida@microsoft.com>

This allows Rust code to get a reference to the current task without
having to increment the refcount, but still guaranteeing memory safety.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: Make `current` a macro to prevent it from escaping the caller

 rust/helpers.c         |  6 +++
 rust/kernel/prelude.rs |  2 +
 rust/kernel/task.rs    | 93 +++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/rust/helpers.c b/rust/helpers.c
index 58a194042c86..96441744030e 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -100,6 +100,12 @@ bool rust_helper_refcount_dec_and_test(refcount_t *r)
 }
 EXPORT_SYMBOL_GPL(rust_helper_refcount_dec_and_test);
 
+struct task_struct *rust_helper_get_current(void)
+{
+	return current;
+}
+EXPORT_SYMBOL_GPL(rust_helper_get_current);
+
 void rust_helper_get_task_struct(struct task_struct *t)
 {
 	get_task_struct(t);
diff --git a/rust/kernel/prelude.rs b/rust/kernel/prelude.rs
index fcdc511d2ce8..c28587d68ebc 100644
--- a/rust/kernel/prelude.rs
+++ b/rust/kernel/prelude.rs
@@ -36,3 +36,5 @@ pub use super::error::{code::*, Error, Result};
 pub use super::{str::CStr, ThisModule};
 
 pub use super::init::{InPlaceInit, Init, PinInit};
+
+pub use super::current;
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
index 8d7a8222990f..468387a5f7eb 100644
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@ -5,7 +5,17 @@
 //! C header: [`include/linux/sched.h`](../../../../include/linux/sched.h).
 
 use crate::bindings;
-use core::{cell::UnsafeCell, ptr};
+use core::{cell::UnsafeCell, marker::PhantomData, ops::Deref, ptr};
+
+/// Returns the currently running task.
+#[macro_export]
+macro_rules! current {
+    () => {
+        // SAFETY: Deref + addr-of below create a temporary `TaskRef` that cannot outlive the
+        // caller.
+        unsafe { &*$crate::task::Task::current() }
+    };
+}
 
 /// Wraps the kernel's `struct task_struct`.
 ///
@@ -13,6 +23,42 @@ use core::{cell::UnsafeCell, ptr};
 ///
 /// Instances of this type are always ref-counted, that is, a call to `get_task_struct` ensures
 /// that the allocation remains valid at least until the matching call to `put_task_struct`.
+///
+/// # Examples
+///
+/// The following is an example of getting the PID of the current thread with zero additional cost
+/// when compared to the C version:
+///
+/// ```
+/// let pid = current!().pid();
+/// ```
+///
+/// Getting the PID of the current process, also zero additional cost:
+///
+/// ```
+/// let pid = current!().group_leader().pid();
+/// ```
+///
+/// Getting the current task and storing it in some struct. The reference count is automatically
+/// incremented when creating `State` and decremented when it is dropped:
+///
+/// ```
+/// use kernel::{task::Task, types::ARef};
+///
+/// struct State {
+///     creator: ARef<Task>,
+///     index: u32,
+/// }
+///
+/// impl State {
+///     fn new() -> Self {
+///         Self {
+///             creator: current!().into(),
+///             index: 0,
+///         }
+///     }
+/// }
+/// ```
 #[repr(transparent)]
 pub struct Task(pub(crate) UnsafeCell<bindings::task_struct>);
 
@@ -25,6 +71,24 @@ unsafe impl Sync for Task {}
 type Pid = bindings::pid_t;
 
 impl Task {
+    /// Returns a task reference for the currently executing task/thread.
+    ///
+    /// # Safety
+    ///
+    /// Callers must ensure that the returned [`TaskRef`] doesn't outlive the current task/thread.
+    pub unsafe fn current<'a>() -> TaskRef<'a> {
+        // SAFETY: Just an FFI call with no additional safety requirements.
+        let ptr = unsafe { bindings::get_current() };
+
+        TaskRef {
+            // SAFETY: If the current thread is still running, the current task is valid. Given
+            // that `TaskRef` is not `Send`, we know it cannot be transferred to another thread
+            // (where it could potentially outlive the caller).
+            task: unsafe { &*ptr.cast() },
+            _not_send: PhantomData,
+        }
+    }
+
     /// Returns the group leader of the given task.
     pub fn group_leader(&self) -> &Task {
         // SAFETY: By the type invariant, we know that `self.0` is valid.
@@ -69,3 +133,30 @@ unsafe impl crate::types::AlwaysRefCounted for Task {
         unsafe { bindings::put_task_struct(obj.cast().as_ptr()) }
     }
 }
+
+/// A wrapper for a shared reference to [`Task`] that isn't [`Send`].
+///
+/// We make this explicitly not [`Send`] so that we can use it to represent the current thread
+/// without having to increment/decrement the task's reference count.
+///
+/// # Invariants
+///
+/// The wrapped [`Task`] remains valid for the lifetime of the object.
+pub struct TaskRef<'a> {
+    task: &'a Task,
+    _not_send: PhantomData<*mut ()>,
+}
+
+impl Deref for TaskRef<'_> {
+    type Target = Task;
+
+    fn deref(&self) -> &Self::Target {
+        self.task
+    }
+}
+
+impl From<TaskRef<'_>> for crate::types::ARef<Task> {
+    fn from(t: TaskRef<'_>) -> Self {
+        t.deref().into()
+    }
+}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 11/13] rust: lock: add `Guard::do_unlocked`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (8 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 10/13] rust: introduce `current` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 12/13] rust: sync: introduce `CondVar` Wedson Almeida Filho
                   ` (3 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

From: Wedson Almeida Filho <walmeida@microsoft.com>

It releases the lock, executes some function provided by the caller,
then reacquires the lock. This is preparation for the implementation of
condvars, which will sleep after between unlocking and relocking.

We need an explicit `relock` method for primitives like `SpinLock` that
have an irqsave variant: we use the guard state to determine if the lock
was originally acquired with the regular `lock` function or
`lock_irqsave`.

Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: No changes

 rust/kernel/sync/lock.rs          | 25 +++++++++++++++++++++++++
 rust/kernel/sync/lock/spinlock.rs | 17 +++++++++++++++--
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index 491446c3a074..ae20277c39c8 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -22,6 +22,9 @@ pub mod spinlock;
 ///
 /// - Implementers must ensure that only one thread/CPU may access the protected data once the lock
 /// is owned, that is, between calls to `lock` and `unlock`.
+/// - Implementers must also ensure that `relock` uses the same locking method as the original
+/// lock operation. For example, it should disable interrupts if [`IrqSaveBackend::lock_irqsave`]
+/// is used.
 pub unsafe trait Backend {
     /// The state required by the lock.
     type State;
@@ -55,6 +58,17 @@ pub unsafe trait Backend {
     ///
     /// It must only be called by the current owner of the lock.
     unsafe fn unlock(ptr: *mut Self::State, guard_state: &Self::GuardState);
+
+    /// Reacquires the lock, making the caller its owner.
+    ///
+    /// # Safety
+    ///
+    /// Callers must ensure that `state` comes from a previous call to [`Backend::lock`] (or
+    /// variant) that has been unlocked with [`Backend::unlock`] and will be relocked now.
+    unsafe fn relock(ptr: *mut Self::State, guard_state: &mut Self::GuardState) {
+        // SAFETY: The safety requirements ensure that the lock is initialised.
+        *guard_state = unsafe { Self::lock(ptr) };
+    }
 }
 
 /// The "backend" of a lock that supports the irq-save variant.
@@ -162,6 +176,17 @@ 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> {
+    #[allow(dead_code)]
+    pub(crate) fn do_unlocked(&mut self, cb: impl FnOnce()) {
+        // SAFETY: The caller owns the lock, so it is safe to unlock it.
+        unsafe { B::unlock(self.lock.state.get(), &self.state) };
+        cb();
+        // SAFETY: The lock was just unlocked above and is being relocked now.
+        unsafe { B::relock(self.lock.state.get(), &mut self.state) };
+    }
+}
+
 impl<T: ?Sized, B: Backend> core::ops::Deref for Guard<'_, T, B> {
     type Target = T;
 
diff --git a/rust/kernel/sync/lock/spinlock.rs b/rust/kernel/sync/lock/spinlock.rs
index 34dec09a97c0..e2a2f68e6d93 100644
--- a/rust/kernel/sync/lock/spinlock.rs
+++ b/rust/kernel/sync/lock/spinlock.rs
@@ -4,6 +4,7 @@
 //!
 //! This module allows Rust code to use the kernel's `spinlock_t`.
 
+use super::IrqSaveBackend;
 use crate::bindings;
 
 /// Creates a [`SpinLock`] initialiser with the given name and a newly-created lock class.
@@ -95,7 +96,8 @@ pub type SpinLock<T> = super::Lock<T, SpinLockBackend>;
 /// A kernel `spinlock_t` lock backend.
 pub struct SpinLockBackend;
 
-// SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion.
+// SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion. `relock` uses the
+// same scheme as `unlock` to figure out which locking method was used originally.
 unsafe impl super::Backend for SpinLockBackend {
     type State = bindings::spinlock_t;
     type GuardState = Option<core::ffi::c_ulong>;
@@ -127,13 +129,24 @@ unsafe impl super::Backend for SpinLockBackend {
             None => unsafe { bindings::spin_unlock(ptr) },
         }
     }
+
+    unsafe fn relock(ptr: *mut Self::State, guard_state: &mut Self::GuardState) {
+        let _ = match guard_state {
+            // SAFETY: The safety requiments of this function ensure that `ptr` has been
+            // initialised.
+            None => unsafe { Self::lock(ptr) },
+            // SAFETY: The safety requiments of this function ensure that `ptr` has been
+            // initialised.
+            Some(_) => unsafe { Self::lock_irqsave(ptr) },
+        };
+    }
 }
 
 // SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion. We use the `irqsave`
 // variant of the C lock acquisition functions to disable interrupts and retrieve the original
 // interrupt state, and the `irqrestore` variant of the lock release functions to restore the state
 // in `unlock` -- we use the guard context to determine which method was used to acquire the lock.
-unsafe impl super::IrqSaveBackend for SpinLockBackend {
+unsafe impl IrqSaveBackend for SpinLockBackend {
     unsafe fn lock_irqsave(ptr: *mut Self::State) -> Self::GuardState {
         // SAFETY: The safety requirements of this function ensure that `ptr` points to valid
         // memory, and that it has been initialised before.
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 12/13] rust: sync: introduce `CondVar`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (9 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 11/13] rust: lock: add `Guard::do_unlocked` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-05 17:51 ` [PATCH v2 13/13] rust: sync: introduce `LockedBy` Wedson Almeida Filho
                   ` (2 subsequent siblings)
  13 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

From: Wedson Almeida Filho <walmeida@microsoft.com>

This is the traditional condition variable or monitor synchronisation
primitive. It is implemented with C's `wait_queue_head_t`.

It allows users to release a lock and go to sleep while guaranteeing
that notifications won't be missed. This is achieved by enqueuing a wait
entry before releasing the lock.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: Use the new `current` macro

 rust/bindings/bindings_helper.h |   1 +
 rust/helpers.c                  |   7 ++
 rust/kernel/sync.rs             |   2 +
 rust/kernel/sync/condvar.rs     | 178 ++++++++++++++++++++++++++++++++
 rust/kernel/sync/lock.rs        |   1 -
 5 files changed, 188 insertions(+), 1 deletion(-)
 create mode 100644 rust/kernel/sync/condvar.rs

diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 03656a44a83f..50e7a76d5455 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -8,6 +8,7 @@
 
 #include <linux/slab.h>
 #include <linux/refcount.h>
+#include <linux/wait.h>
 #include <linux/sched.h>
 
 /* `bindgen` gets confused at certain things. */
diff --git a/rust/helpers.c b/rust/helpers.c
index 96441744030e..8ff2559c1572 100644
--- a/rust/helpers.c
+++ b/rust/helpers.c
@@ -24,6 +24,7 @@
 #include <linux/mutex.h>
 #include <linux/spinlock.h>
 #include <linux/sched/signal.h>
+#include <linux/wait.h>
 
 __noreturn void rust_helper_BUG(void)
 {
@@ -76,6 +77,12 @@ void rust_helper_spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
 }
 EXPORT_SYMBOL_GPL(rust_helper_spin_unlock_irqrestore);
 
+void rust_helper_init_wait(struct wait_queue_entry *wq_entry)
+{
+	init_wait(wq_entry);
+}
+EXPORT_SYMBOL_GPL(rust_helper_init_wait);
+
 int rust_helper_signal_pending(struct task_struct *t)
 {
 	return signal_pending(t);
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index ed07437d7d55..d6dd0e2c1678 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -8,9 +8,11 @@
 use crate::types::Opaque;
 
 mod arc;
+mod condvar;
 pub mod lock;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
+pub use condvar::CondVar;
 pub use lock::{mutex::Mutex, spinlock::SpinLock};
 
 /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
new file mode 100644
index 000000000000..9de76110e6b5
--- /dev/null
+++ b/rust/kernel/sync/condvar.rs
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! A condition variable.
+//!
+//! This module allows Rust code to use the kernel's [`struct wait_queue_head`] as a condition
+//! variable.
+
+use super::{lock::Backend, lock::Guard, LockClassKey};
+use crate::{bindings, init::PinInit, pin_init, str::CStr, types::Opaque};
+use core::marker::PhantomPinned;
+use macros::pin_data;
+
+/// Creates a [`CondVar`] initialiser with the given name and a newly-created lock class.
+#[macro_export]
+macro_rules! new_condvar {
+    ($($name:literal)?) => {
+        $crate::sync::CondVar::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+
+/// A conditional variable.
+///
+/// Exposes the kernel's [`struct wait_queue_head`] as a condition variable. It allows the caller to
+/// atomically release the given lock and go to sleep. It reacquires the lock when it wakes up. And
+/// it wakes up when notified by another thread (via [`CondVar::notify_one`] or
+/// [`CondVar::notify_all`]) or because the thread received a signal. It may also wake up
+/// spuriously.
+///
+/// Instances of [`CondVar`] need a lock class and to be pinned. The recommended way to create such
+/// instances is with the [`pin_init`](crate::pin_init) and [`new_condvar`] macros.
+///
+/// # Examples
+///
+/// The following is an example of using a condvar with a mutex:
+///
+/// ```
+/// use kernel::sync::{CondVar, Mutex};
+/// use kernel::{new_condvar, new_mutex};
+///
+/// #[pin_data]
+/// pub struct Example {
+///     #[pin]
+///     value: Mutex<u32>,
+///
+///     #[pin]
+///     value_changed: CondVar,
+/// }
+///
+/// /// Waits for `e.value` to become `v`.
+/// fn wait_for_vaue(e: &Example, v: u32) {
+///     let mut guard = e.value.lock();
+///     while *guard != v {
+///         e.value_changed.wait_uninterruptible(&mut guard);
+///     }
+/// }
+///
+/// /// Increments `e.value` and notifies all potential waiters.
+/// fn increment(e: &Example) {
+///     *e.value.lock() += 1;
+///     e.value_changed.notify_all();
+/// }
+///
+/// /// Allocates a new boxed `Example`.
+/// fn new_example() -> Result<Pin<Box<Example>>> {
+///     Box::pin_init(pin_init!(Example {
+///         value <- new_mutex!(0),
+///         value_changed <- new_condvar!(),
+///     }))
+/// }
+/// ```
+///
+/// [`struct wait_queue_head`]: ../../../include/linux/wait.h
+#[pin_data]
+pub struct CondVar {
+    #[pin]
+    pub(crate) wait_list: Opaque<bindings::wait_queue_head>,
+
+    /// A condvar needs to be pinned because it contains a [`struct list_head`] that is
+    /// self-referential, so it cannot be safely moved once it is initialised.
+    #[pin]
+    _pin: PhantomPinned,
+}
+
+// SAFETY: `CondVar` only uses a `struct wait_queue_head`, which is safe to use on any thread.
+#[allow(clippy::non_send_fields_in_send_ty)]
+unsafe impl Send for CondVar {}
+
+// SAFETY: `CondVar` only uses a `struct wait_queue_head`, which is safe to use on multiple threads
+// concurrently.
+unsafe impl Sync for CondVar {}
+
+impl CondVar {
+    /// Constructs a new condvar initialiser.
+    #[allow(clippy::new_ret_no_self)]
+    pub fn new(name: &'static CStr, key: &'static LockClassKey) -> impl PinInit<Self> {
+        pin_init!(Self {
+            _pin: PhantomPinned,
+            // SAFETY: `__init_waitqueue_head` initialises the waitqueue head, and both `name` and
+            // `key` have static lifetimes so they live indefinitely.
+            wait_list <- unsafe {
+                Opaque::ffi_init2(
+                    bindings::__init_waitqueue_head,
+                    name.as_char_ptr(),
+                    key.as_ptr(),
+                )
+            },
+        })
+    }
+
+    fn wait_internal<T: ?Sized, B: Backend>(&self, wait_state: u32, guard: &mut Guard<'_, T, B>) {
+        let wait = Opaque::<bindings::wait_queue_entry>::uninit();
+
+        // SAFETY: `wait` points to valid memory.
+        unsafe { bindings::init_wait(wait.get()) };
+
+        // SAFETY: Both `wait` and `wait_list` point to valid memory.
+        unsafe {
+            bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)
+        };
+
+        // SAFETY: No arguments, switches to another thread.
+        guard.do_unlocked(|| unsafe { bindings::schedule() });
+
+        // SAFETY: Both `wait` and `wait_list` point to valid memory.
+        unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
+    }
+
+    /// 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
+    /// thread to sleep, reacquiring the lock on wake up. It wakes up when notified by
+    /// [`CondVar::notify_one`] or [`CondVar::notify_all`], or when the thread receives a signal.
+    /// It may also wake up spuriously.
+    ///
+    /// Returns whether there is a signal pending.
+    #[must_use = "wait returns if a signal is pending, so the caller must check the return value"]
+    pub fn wait<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T, B>) -> bool {
+        self.wait_internal(bindings::TASK_INTERRUPTIBLE, guard);
+        crate::current!().signal_pending()
+    }
+
+    /// Releases the lock and waits for a notification in uninterruptible mode.
+    ///
+    /// Similar to [`CondVar::wait`], except that the wait is not interruptible. That is, the
+    /// thread won't wake up due to signals. It may, however, wake up supirously.
+    pub fn wait_uninterruptible<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T, B>) {
+        self.wait_internal(bindings::TASK_UNINTERRUPTIBLE, guard)
+    }
+
+    /// Calls the kernel function to notify the appropriate number of threads with the given flags.
+    fn notify(&self, count: i32, flags: u32) {
+        // SAFETY: `wait_list` points to valid memory.
+        unsafe {
+            bindings::__wake_up(
+                self.wait_list.get(),
+                bindings::TASK_NORMAL,
+                count,
+                flags as _,
+            )
+        };
+    }
+
+    /// Wakes a single waiter up, if any.
+    ///
+    /// This is not 'sticky' in the sense that if no thread is waiting, the notification is lost
+    /// completely (as opposed to automatically waking up the next waiter).
+    pub fn notify_one(&self) {
+        self.notify(1, 0);
+    }
+
+    /// Wakes all waiters up, if any.
+    ///
+    /// This is not 'sticky' in the sense that if no thread is waiting, the notification is lost
+    /// completely (as opposed to automatically waking up the next waiter).
+    pub fn notify_all(&self) {
+        self.notify(0, 0);
+    }
+}
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index ae20277c39c8..f52ba9ab1b70 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -177,7 +177,6 @@ pub struct Guard<'a, T: ?Sized, B: Backend> {
 unsafe impl<T: Sync + ?Sized, B: Backend> Sync for Guard<'_, T, B> {}
 
 impl<T: ?Sized, B: Backend> Guard<'_, T, B> {
-    #[allow(dead_code)]
     pub(crate) fn do_unlocked(&mut self, cb: impl FnOnce()) {
         // SAFETY: The caller owns the lock, so it is safe to unlock it.
         unsafe { B::unlock(self.lock.state.get(), &self.state) };
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH v2 13/13] rust: sync: introduce `LockedBy`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (10 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 12/13] rust: sync: introduce `CondVar` Wedson Almeida Filho
@ 2023-04-05 17:51 ` Wedson Almeida Filho
  2023-04-07 21:00   ` Benno Lossin
  2023-04-05 18:00 ` [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Greg KH
  2023-04-05 20:21 ` Gary Guo
  13 siblings, 1 reply; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 17:51 UTC (permalink / raw)
  To: rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

From: Wedson Almeida Filho <walmeida@microsoft.com>

This allows us to have data protected by a lock despite not being
wrapped by it. Access is granted by providing evidence that the lock is
held by the caller.

Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
---
v1 -> v2: Added build_assert to rule out zero-sized types

 rust/kernel/sync.rs           |   2 +
 rust/kernel/sync/lock.rs      |   2 +-
 rust/kernel/sync/locked_by.rs | 128 ++++++++++++++++++++++++++++++++++
 3 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 rust/kernel/sync/locked_by.rs

diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index d6dd0e2c1678..f8edb6d0d794 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -10,10 +10,12 @@ use crate::types::Opaque;
 mod arc;
 mod condvar;
 pub mod lock;
+mod locked_by;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use condvar::CondVar;
 pub use lock::{mutex::Mutex, spinlock::SpinLock};
+pub use locked_by::LockedBy;
 
 /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
 #[repr(transparent)]
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index f52ba9ab1b70..51c996ca2109 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -111,7 +111,7 @@ pub struct Lock<T: ?Sized, B: Backend> {
     _pin: PhantomPinned,
 
     /// The data protected by the lock.
-    data: UnsafeCell<T>,
+    pub(crate) data: UnsafeCell<T>,
 }
 
 // SAFETY: `Lock` can be transferred across thread boundaries iff the data it protects can.
diff --git a/rust/kernel/sync/locked_by.rs b/rust/kernel/sync/locked_by.rs
new file mode 100644
index 000000000000..191e37d804e5
--- /dev/null
+++ b/rust/kernel/sync/locked_by.rs
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! A wrapper for data protected by a lock that does not wrap it.
+
+use super::{lock::Backend, lock::Lock};
+use core::{cell::UnsafeCell, ptr};
+
+/// Allows access to some data to be serialised by a lock that does not wrap it.
+///
+/// In most cases, data protected by a lock is wrapped by the appropriate lock type, e.g.,
+/// [`super::Mutex`] or [`super::SpinLock`]. [`LockedBy`] is meant for cases when this is not
+/// possible. For example, if a container has a lock and some data in the contained elements needs
+/// to be protected by the same lock.
+///
+/// [`LockedBy`] wraps the data in lieu of another locking primitive, and only allows access to it
+/// when the caller shows evidence that the 'external' lock is locked.
+///
+/// # Examples
+///
+/// The following is an example for illustrative purposes: `InnerDirectory::bytes_used` is an
+/// aggregate of all `InnerFile::bytes_used` and must be kept consistent; so we wrap `InnerFile` in
+/// a `LockedBy` so that it shares a lock with `InnerDirectory`. This allows us to enforce at
+/// compile-time that access to `InnerFile` is only granted when an `InnerDirectory` is also
+/// locked; we enforce at run time that the right `InnerDirectory` is locked.
+///
+/// ```
+/// use kernel::sync::{LockedBy, Mutex};
+///
+/// struct InnerFile {
+///     bytes_used: u64,
+/// }
+///
+/// struct File {
+///     _ino: u32,
+///     inner: LockedBy<InnerFile, InnerDirectory>,
+/// }
+///
+/// struct InnerDirectory {
+///     /// The sum of the bytes used by all files.
+///     bytes_used: u64,
+///     _files: Vec<File>,
+/// }
+///
+/// struct Directory {
+///     _ino: u32,
+///     inner: Mutex<InnerDirectory>,
+/// }
+///
+/// /// Prints `bytes_used` from both the directory and file.
+/// fn print_bytes_used(dir: &Directory, file: &File) {
+///     let guard = dir.inner.lock();
+///     let inner_file = file.inner.access(&guard);
+///     pr_info!("{} {}", guard.bytes_used, inner_file.bytes_used);
+/// }
+///
+/// /// Increments `bytes_used` for both the directory and file.
+/// fn inc_bytes_used(dir: &Directory, file: &File) {
+///     let mut guard = dir.inner.lock();
+///     guard.bytes_used += 10;
+///
+///     let file_inner = file.inner.access_mut(&mut guard);
+///     file_inner.bytes_used += 10;
+/// }
+///
+/// /// Creates a new file.
+/// fn new_file(ino: u32, dir: &Directory) -> File {
+///     File {
+///         _ino: ino,
+///         inner: LockedBy::new(&dir.inner, InnerFile { bytes_used: 0 }),
+///     }
+/// }
+/// ```
+pub struct LockedBy<T: ?Sized, U: ?Sized> {
+    owner: *const U,
+    data: UnsafeCell<T>,
+}
+
+// SAFETY: `LockedBy` can be transferred across thread boundaries iff the data it protects can.
+unsafe impl<T: ?Sized + Send, U: ?Sized> Send for LockedBy<T, U> {}
+
+// SAFETY: `LockedBy` serialises the interior mutability it provides, so it is `Sync` as long as the
+// data it protects is `Send`.
+unsafe impl<T: ?Sized + Send, U: ?Sized> Sync for LockedBy<T, U> {}
+
+impl<T, U: ?Sized> LockedBy<T, U> {
+    /// Constructs a new instance of [`LockedBy`].
+    ///
+    /// It stores a raw pointer to the owner that is never dereferenced. It is only used to ensure
+    /// that the right owner is being used to access the protected data. If the owner is freed, the
+    /// data becomes inaccessible; if another instance of the owner is allocated *on the same
+    /// memory location*, the data becomes accessible again: none of this affects memory safety
+    /// because in any case at most one thread (or CPU) can access the protected data at a time.
+    pub fn new(owner: &Lock<U, impl Backend>, data: T) -> Self {
+        Self {
+            owner: owner.data.get(),
+            data: UnsafeCell::new(data),
+        }
+    }
+}
+
+impl<T: ?Sized, U> LockedBy<T, U> {
+    /// Returns a reference to the protected data when the caller provides evidence (via a
+    /// reference) that the owner is locked.
+    pub fn access<'a>(&'a self, owner: &'a U) -> &'a T {
+        crate::build_assert!(core::mem::size_of::<U>() > 0);
+        if !ptr::eq(owner, self.owner) {
+            panic!("mismatched owners");
+        }
+
+        // SAFETY: `owner` is evidence that the owner is locked.
+        unsafe { &*self.data.get() }
+    }
+
+    /// Returns a mutable reference to the protected data when the caller provides evidence (via a
+    /// mutable owner) that the owner is locked mutably.
+    ///
+    /// Showing a mutable reference to the owner is sufficient because we know no other references
+    /// can exist to it.
+    pub fn access_mut<'a>(&'a self, owner: &'a mut U) -> &'a mut T {
+        crate::build_assert!(core::mem::size_of::<U>() > 0);
+        if !ptr::eq(owner, self.owner) {
+            panic!("mismatched owners");
+        }
+
+        // SAFETY: `owner` is evidence that there is only one reference to the owner.
+        unsafe { &mut *self.data.get() }
+    }
+}
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 01/13] rust: sync: introduce `LockClassKey`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (11 preceding siblings ...)
  2023-04-05 17:51 ` [PATCH v2 13/13] rust: sync: introduce `LockedBy` Wedson Almeida Filho
@ 2023-04-05 18:00 ` Greg KH
  2023-04-05 20:05   ` Wedson Almeida Filho
  2023-04-05 20:21 ` Gary Guo
  13 siblings, 1 reply; 34+ messages in thread
From: Greg KH @ 2023-04-05 18:00 UTC (permalink / raw)
  To: Wedson Almeida Filho
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 02:50:59PM -0300, Wedson Almeida Filho wrote:
> From: Wedson Almeida Filho <walmeida@microsoft.com>
> 
> It is a wrapper around C's `lock_class_key`, which is used by the
> synchronisation primitives that are checked with lockdep. This is in
> preparation for introducing Rust abstractions for these primitives.
> 
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Waiman Long <longman@redhat.com>
> Co-developed-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> ---
> v1 -> v2: Fixed a typo in comment
> 
>  rust/kernel/sync.rs | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
> index 33da23e3076d..84a4b560828c 100644
> --- a/rust/kernel/sync.rs
> +++ b/rust/kernel/sync.rs
> @@ -5,6 +5,51 @@
>  //! 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::types::Opaque;
> +
>  mod arc;
>  
>  pub use arc::{Arc, ArcBorrow, UniqueArc};
> +
> +/// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
> +#[repr(transparent)]
> +pub struct LockClassKey(Opaque<bindings::lock_class_key>);

Will this disappear into "nothing" if lockdep is disabled in the build?

If not, it should, if so, I couldn't see where that option was, sorry
for the noise.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 17:51 ` [PATCH v2 03/13] rust: lock: introduce `Mutex` Wedson Almeida Filho
@ 2023-04-05 18:03   ` Greg KH
  2023-04-05 18:04     ` Greg KH
  0 siblings, 1 reply; 34+ messages in thread
From: Greg KH @ 2023-04-05 18:03 UTC (permalink / raw)
  To: Wedson Almeida Filho
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> +void rust_helper_mutex_lock(struct mutex *lock)
> +{
> +	mutex_lock(lock);
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> +

No need to ever unlock a mutex?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 18:03   ` Greg KH
@ 2023-04-05 18:04     ` Greg KH
  2023-04-05 19:18       ` Peter Zijlstra
  0 siblings, 1 reply; 34+ messages in thread
From: Greg KH @ 2023-04-05 18:04 UTC (permalink / raw)
  To: Wedson Almeida Filho
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > +void rust_helper_mutex_lock(struct mutex *lock)
> > +{
> > +	mutex_lock(lock);
> > +}
> > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > +
> 
> No need to ever unlock a mutex?

Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 18:04     ` Greg KH
@ 2023-04-05 19:18       ` Peter Zijlstra
  2023-04-05 20:21         ` Wedson Almeida Filho
  0 siblings, 1 reply; 34+ messages in thread
From: Peter Zijlstra @ 2023-04-05 19:18 UTC (permalink / raw)
  To: Greg KH
  Cc: Wedson Almeida Filho, rust-for-linux, Miguel Ojeda, Alex Gaynor,
	Boqun Feng, Gary Guo, Björn Roy Baron, linux-kernel,
	Wedson Almeida Filho, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 08:04:22PM +0200, Greg KH wrote:
> On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> > On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > > +void rust_helper_mutex_lock(struct mutex *lock)
> > > +{
> > > +	mutex_lock(lock);
> > > +}
> > > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > > +
> > 
> > No need to ever unlock a mutex?
> 
> Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...

Yeah, so I despise all these stupid helpers... but I suppose it's the
best they could come up with to interface the languages :/

The only hope is that the thing can do cross-language LTO or something
to re-inline stuff.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 01/13] rust: sync: introduce `LockClassKey`
  2023-04-05 18:00 ` [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Greg KH
@ 2023-04-05 20:05   ` Wedson Almeida Filho
  0 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 20:05 UTC (permalink / raw)
  To: Greg KH
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 08:00:15PM +0200, Greg KH wrote:
> On Wed, Apr 05, 2023 at 02:50:59PM -0300, Wedson Almeida Filho wrote:
> > From: Wedson Almeida Filho <walmeida@microsoft.com>
> > 
> > +/// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
> > +#[repr(transparent)]
> > +pub struct LockClassKey(Opaque<bindings::lock_class_key>);
> 
> Will this disappear into "nothing" if lockdep is disabled in the build?
> 
> If not, it should, if so, I couldn't see where that option was, sorry
> for the noise.

Yeah, the C definition of lock_class_key is an empty struct, which is a
zero-sized type. So instances of this type will occupy 0 bytes.

We'll still have the cost of passing pointers from Rust to C of instances of
this type, which we could add an alternate version (dependent on lockdep being
enabled or not) in Rust to avoid, but since it will be optimised away when LTO
is enabled and doesn't add up to much when LTO is disabled, we chose the simpler
option of having a single implementation.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 19:18       ` Peter Zijlstra
@ 2023-04-05 20:21         ` Wedson Almeida Filho
  2023-04-05 20:29           ` Peter Zijlstra
  0 siblings, 1 reply; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 20:21 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Greg KH, rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng,
	Gary Guo, Björn Roy Baron, linux-kernel,
	Wedson Almeida Filho, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 09:18:26PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 05, 2023 at 08:04:22PM +0200, Greg KH wrote:
> > On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> > > On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > > > +void rust_helper_mutex_lock(struct mutex *lock)
> > > > +{
> > > > +	mutex_lock(lock);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > > > +
> > > 
> > > No need to ever unlock a mutex?
> > 
> > Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...
> 
> Yeah, so I despise all these stupid helpers... but I suppose it's the
> best they could come up with to interface the languages :/
> 
> The only hope is that the thing can do cross-language LTO or something
> to re-inline stuff.

One thing we could to do improve the situation is to convert some of the
existing macros into inline functions on the header files.

We can't do it for all cases (e.g., cases like mutex_init that declare a new
static variable when lockdep is enabled) but mutex_lock is just a function
when lockdep is disabled, and just calls mutex_lock_nested() when it is enabled.

How do you feel about this?

-#define mutex_lock(lock) mutex_lock_nested(lock, 0)
+static inline void mutex_lock(struct mutex *lock)
+{
+       mutex_lock_nested(lock, 0);
+}
+

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 01/13] rust: sync: introduce `LockClassKey`
  2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
                   ` (12 preceding siblings ...)
  2023-04-05 18:00 ` [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Greg KH
@ 2023-04-05 20:21 ` Gary Guo
  13 siblings, 0 replies; 34+ messages in thread
From: Gary Guo @ 2023-04-05 20:21 UTC (permalink / raw)
  To: Wedson Almeida Filho
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long

On Wed,  5 Apr 2023 14:50:59 -0300
Wedson Almeida Filho <wedsonaf@gmail.com> wrote:

> From: Wedson Almeida Filho <walmeida@microsoft.com>
> 
> It is a wrapper around C's `lock_class_key`, which is used by the
> synchronisation primitives that are checked with lockdep. This is in
> preparation for introducing Rust abstractions for these primitives.
> 
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Waiman Long <longman@redhat.com>
> Co-developed-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> ---
> v1 -> v2: Fixed a typo in comment
> 
>  rust/kernel/sync.rs | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
> index 33da23e3076d..84a4b560828c 100644
> --- a/rust/kernel/sync.rs
> +++ b/rust/kernel/sync.rs
> @@ -5,6 +5,51 @@
>  //! 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::types::Opaque;
> +
>  mod arc;
>  
>  pub use arc::{Arc, ArcBorrow, UniqueArc};
> +
> +/// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
> +#[repr(transparent)]
> +pub struct LockClassKey(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 {
> +    /// Creates a new lock class key.
> +    pub const fn new() -> Self {
> +        Self(Opaque::uninit())
> +    }
> +
> +    #[allow(dead_code)]
> +    pub(crate) fn as_ptr(&self) -> *mut bindings::lock_class_key {
> +        self.0.get()
> +    }
> +}
> +
> +/// 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();
> +        &CLASS
> +    }};
> +}
> +
> +/// Returns the given string, if one is provided, otherwise generates one based on the source code
> +/// location.
> +#[doc(hidden)]
> +#[macro_export]
> +macro_rules! optional_name {
> +    () => {
> +        $crate::c_str!(core::concat!(core::file!(), ":", core::line!()))

nit: prefer `::core` to `core` in macro.

> +    };
> +    ($name:literal) => {
> +        $crate::c_str!($name)
> +    };
> +}


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 20:21         ` Wedson Almeida Filho
@ 2023-04-05 20:29           ` Peter Zijlstra
  2023-04-05 20:40             ` Wedson Almeida Filho
  0 siblings, 1 reply; 34+ messages in thread
From: Peter Zijlstra @ 2023-04-05 20:29 UTC (permalink / raw)
  To: Wedson Almeida Filho
  Cc: Greg KH, rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng,
	Gary Guo, Björn Roy Baron, linux-kernel,
	Wedson Almeida Filho, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 05:21:44PM -0300, Wedson Almeida Filho wrote:
> On Wed, Apr 05, 2023 at 09:18:26PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 05, 2023 at 08:04:22PM +0200, Greg KH wrote:
> > > On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> > > > On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > > > > +void rust_helper_mutex_lock(struct mutex *lock)
> > > > > +{
> > > > > +	mutex_lock(lock);
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > > > > +
> > > > 
> > > > No need to ever unlock a mutex?
> > > 
> > > Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...
> > 
> > Yeah, so I despise all these stupid helpers... but I suppose it's the
> > best they could come up with to interface the languages :/
> > 
> > The only hope is that the thing can do cross-language LTO or something
> > to re-inline stuff.
> 
> One thing we could to do improve the situation is to convert some of the
> existing macros into inline functions on the header files.
> 
> We can't do it for all cases (e.g., cases like mutex_init that declare a new
> static variable when lockdep is enabled) but mutex_lock is just a function
> when lockdep is disabled, and just calls mutex_lock_nested() when it is enabled.
> 
> How do you feel about this?
> 
> -#define mutex_lock(lock) mutex_lock_nested(lock, 0)
> +static inline void mutex_lock(struct mutex *lock)
> +{
> +       mutex_lock_nested(lock, 0);
> +}

Can rust actually parse C headers and inline C functions ? I thought the
whole problem was that it can only call C ABI symbols (which inline
functions are not).

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 20:29           ` Peter Zijlstra
@ 2023-04-05 20:40             ` Wedson Almeida Filho
  2023-04-05 20:49               ` Peter Zijlstra
  0 siblings, 1 reply; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-05 20:40 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Greg KH, rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng,
	Gary Guo, Björn Roy Baron, linux-kernel,
	Wedson Almeida Filho, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 10:29:32PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 05, 2023 at 05:21:44PM -0300, Wedson Almeida Filho wrote:
> > On Wed, Apr 05, 2023 at 09:18:26PM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 05, 2023 at 08:04:22PM +0200, Greg KH wrote:
> > > > On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> > > > > On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > > > > > +void rust_helper_mutex_lock(struct mutex *lock)
> > > > > > +{
> > > > > > +	mutex_lock(lock);
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > > > > > +
> > > > > 
> > > > > No need to ever unlock a mutex?
> > > > 
> > > > Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...
> > > 
> > > Yeah, so I despise all these stupid helpers... but I suppose it's the
> > > best they could come up with to interface the languages :/
> > > 
> > > The only hope is that the thing can do cross-language LTO or something
> > > to re-inline stuff.
> > 
> > One thing we could to do improve the situation is to convert some of the
> > existing macros into inline functions on the header files.
> > 
> > We can't do it for all cases (e.g., cases like mutex_init that declare a new
> > static variable when lockdep is enabled) but mutex_lock is just a function
> > when lockdep is disabled, and just calls mutex_lock_nested() when it is enabled.
> > 
> > How do you feel about this?
> > 
> > -#define mutex_lock(lock) mutex_lock_nested(lock, 0)
> > +static inline void mutex_lock(struct mutex *lock)
> > +{
> > +       mutex_lock_nested(lock, 0);
> > +}
> 
> Can rust actually parse C headers and inline C functions ? I thought the
> whole problem was that it can only call C ABI symbols (which inline
> functions are not).

Rust can't. We use a tool called bindgen to read C header files and generate
equivalent Rust (extern "C") declarations for functions. The tool has been
enhanced recently (https://github.com/rust-lang/rust-bindgen/pull/2335) to
handle static inline functions by automatically generating helpers like the one
above (in addition to the Rust decls).

So the situation is improved in that we don't need to manually write (and
commit) the helpers. It may improve further in the future if we get better
integration of the languages.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 20:40             ` Wedson Almeida Filho
@ 2023-04-05 20:49               ` Peter Zijlstra
  2023-04-06  8:38                 ` David Laight
  2023-04-06 16:45                 ` Miguel Ojeda
  0 siblings, 2 replies; 34+ messages in thread
From: Peter Zijlstra @ 2023-04-05 20:49 UTC (permalink / raw)
  To: Wedson Almeida Filho
  Cc: Greg KH, rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng,
	Gary Guo, Björn Roy Baron, linux-kernel,
	Wedson Almeida Filho, Ingo Molnar, Will Deacon, Waiman Long

On Wed, Apr 05, 2023 at 05:40:39PM -0300, Wedson Almeida Filho wrote:
> On Wed, Apr 05, 2023 at 10:29:32PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 05, 2023 at 05:21:44PM -0300, Wedson Almeida Filho wrote:
> > > On Wed, Apr 05, 2023 at 09:18:26PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Apr 05, 2023 at 08:04:22PM +0200, Greg KH wrote:
> > > > > On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> > > > > > On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > > > > > > +void rust_helper_mutex_lock(struct mutex *lock)
> > > > > > > +{
> > > > > > > +	mutex_lock(lock);
> > > > > > > +}
> > > > > > > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > > > > > > +
> > > > > > 
> > > > > > No need to ever unlock a mutex?
> > > > > 
> > > > > Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...
> > > > 
> > > > Yeah, so I despise all these stupid helpers... but I suppose it's the
> > > > best they could come up with to interface the languages :/
> > > > 
> > > > The only hope is that the thing can do cross-language LTO or something
> > > > to re-inline stuff.
> > > 
> > > One thing we could to do improve the situation is to convert some of the
> > > existing macros into inline functions on the header files.
> > > 
> > > We can't do it for all cases (e.g., cases like mutex_init that declare a new
> > > static variable when lockdep is enabled) but mutex_lock is just a function
> > > when lockdep is disabled, and just calls mutex_lock_nested() when it is enabled.
> > > 
> > > How do you feel about this?
> > > 
> > > -#define mutex_lock(lock) mutex_lock_nested(lock, 0)
> > > +static inline void mutex_lock(struct mutex *lock)
> > > +{
> > > +       mutex_lock_nested(lock, 0);
> > > +}
> > 
> > Can rust actually parse C headers and inline C functions ? I thought the
> > whole problem was that it can only call C ABI symbols (which inline
> > functions are not).
> 
> Rust can't. We use a tool called bindgen to read C header files and generate
> equivalent Rust (extern "C") declarations for functions. The tool has been
> enhanced recently (https://github.com/rust-lang/rust-bindgen/pull/2335) to
> handle static inline functions by automatically generating helpers like the one
> above (in addition to the Rust decls).

Oh man, that's sad, I was hoping it would write the equivalent inline
function in rust.

> So the situation is improved in that we don't need to manually write (and
> commit) the helpers. It may improve further in the future if we get better
> integration of the languages.

But yeah, feel free to convert macros to inline functions where the
difference is moot. There is indeed no real reason for mutex_lock() to
not be an inline function in that case.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* RE: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 20:49               ` Peter Zijlstra
@ 2023-04-06  8:38                 ` David Laight
  2023-04-06 11:21                   ` Marco Elver
  2023-04-06 16:45                 ` Miguel Ojeda
  1 sibling, 1 reply; 34+ messages in thread
From: David Laight @ 2023-04-06  8:38 UTC (permalink / raw)
  To: 'Peter Zijlstra', Wedson Almeida Filho
  Cc: Greg KH, rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng,
	Gary Guo, Björn Roy Baron, linux-kernel,
	Wedson Almeida Filho, Ingo Molnar, Will Deacon, Waiman Long

From: Peter Zijlstra
> Sent: 05 April 2023 21:50
> 
> On Wed, Apr 05, 2023 at 05:40:39PM -0300, Wedson Almeida Filho wrote:
...
> > So the situation is improved in that we don't need to manually write (and
> > commit) the helpers. It may improve further in the future if we get better
> > integration of the languages.
> 
> But yeah, feel free to convert macros to inline functions where the
> difference is moot. There is indeed no real reason for mutex_lock() to
> not be an inline function in that case.

mutex_lock() is probably ok.
But there are cases where gcc generates much better code
for #defines than for inline functions.
Almost certainly because the front end gets to optimise
#defines, but inlines are done much later on.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-06  8:38                 ` David Laight
@ 2023-04-06 11:21                   ` Marco Elver
  2023-04-06 16:25                     ` Miguel Ojeda
  0 siblings, 1 reply; 34+ messages in thread
From: Marco Elver @ 2023-04-06 11:21 UTC (permalink / raw)
  To: David Laight
  Cc: Peter Zijlstra, Wedson Almeida Filho, Greg KH, rust-for-linux,
	Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Ingo Molnar, Will Deacon, Waiman Long

On Thu, 6 Apr 2023 at 10:38, David Laight <David.Laight@aculab.com> wrote:
>
> From: Peter Zijlstra
> > Sent: 05 April 2023 21:50
> >
> > On Wed, Apr 05, 2023 at 05:40:39PM -0300, Wedson Almeida Filho wrote:
> ...
> > > So the situation is improved in that we don't need to manually write (and
> > > commit) the helpers. It may improve further in the future if we get better
> > > integration of the languages.
> >
> > But yeah, feel free to convert macros to inline functions where the
> > difference is moot. There is indeed no real reason for mutex_lock() to
> > not be an inline function in that case.
>
> mutex_lock() is probably ok.
> But there are cases where gcc generates much better code
> for #defines than for inline functions.
> Almost certainly because the front end gets to optimise
> #defines, but inlines are done much later on.

For macro to inline function conversions, the most conservative option
would be __always_inline. We've also seen things go wrong with
"inline" only paired with various kinds of instrumentation.

Can bindgen deal with "static __always_inline" functions?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-06 11:21                   ` Marco Elver
@ 2023-04-06 16:25                     ` Miguel Ojeda
  0 siblings, 0 replies; 34+ messages in thread
From: Miguel Ojeda @ 2023-04-06 16:25 UTC (permalink / raw)
  To: Marco Elver
  Cc: David Laight, Peter Zijlstra, Wedson Almeida Filho, Greg KH,
	rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Ingo Molnar, Will Deacon, Waiman Long

On Thu, Apr 6, 2023 at 1:22 PM Marco Elver <elver@google.com> wrote:
>
> For macro to inline function conversions, the most conservative option
> would be __always_inline. We've also seen things go wrong with
> "inline" only paired with various kinds of instrumentation.
>
> Can bindgen deal with "static __always_inline" functions?

If you mean the new feature where `bindgen` generates wrappers
automatically, it seems to handle them given `__always_inline` =>
`inline` which is what I imagine it looks for (I assume it does not
care about the actual attribute), though I haven't tried to use the
feature within the kernel yet.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
  2023-04-05 20:49               ` Peter Zijlstra
  2023-04-06  8:38                 ` David Laight
@ 2023-04-06 16:45                 ` Miguel Ojeda
  1 sibling, 0 replies; 34+ messages in thread
From: Miguel Ojeda @ 2023-04-06 16:45 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Wedson Almeida Filho, Greg KH, rust-for-linux, Miguel Ojeda,
	Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron,
	linux-kernel, Wedson Almeida Filho, Ingo Molnar, Will Deacon,
	Waiman Long

On Wed, Apr 5, 2023 at 10:49 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> Oh man, that's sad, I was hoping it would write the equivalent inline
> function in rust.

Some of us hope Rust would directly handle importing C headers, so
avoiding the intermediate step, like a few languages support.

> But yeah, feel free to convert macros to inline functions where the
> difference is moot. There is indeed no real reason for mutex_lock() to
> not be an inline function in that case.

We initially minimized changes on the C side on purpose, but if
maintainers are OK with that (modulo exceptions), it would be great.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 13/13] rust: sync: introduce `LockedBy`
  2023-04-05 17:51 ` [PATCH v2 13/13] rust: sync: introduce `LockedBy` Wedson Almeida Filho
@ 2023-04-07 21:00   ` Benno Lossin
  2023-04-08  4:11     ` Wedson Almeida Filho
  0 siblings, 1 reply; 34+ messages in thread
From: Benno Lossin @ 2023-04-07 21:00 UTC (permalink / raw)
  To: Wedson Almeida Filho, rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

On 05.04.23 19:51, Wedson Almeida Filho wrote:
> From: Wedson Almeida Filho <walmeida@microsoft.com>
>
> This allows us to have data protected by a lock despite not being
> wrapped by it. Access is granted by providing evidence that the lock is
> held by the caller.
>
> Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> ---
> v1 -> v2: Added build_assert to rule out zero-sized types
>
>   rust/kernel/sync.rs           |   2 +
>   rust/kernel/sync/lock.rs      |   2 +-
>   rust/kernel/sync/locked_by.rs | 128 ++++++++++++++++++++++++++++++++++
>   3 files changed, 131 insertions(+), 1 deletion(-)
>   create mode 100644 rust/kernel/sync/locked_by.rs
>
> diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
> index d6dd0e2c1678..f8edb6d0d794 100644
> --- a/rust/kernel/sync.rs
> +++ b/rust/kernel/sync.rs
> @@ -10,10 +10,12 @@ use crate::types::Opaque;
>   mod arc;
>   mod condvar;
>   pub mod lock;
> +mod locked_by;
>
>   pub use arc::{Arc, ArcBorrow, UniqueArc};
>   pub use condvar::CondVar;
>   pub use lock::{mutex::Mutex, spinlock::SpinLock};
> +pub use locked_by::LockedBy;
>
>   /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
>   #[repr(transparent)]
> diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
> index f52ba9ab1b70..51c996ca2109 100644
> --- a/rust/kernel/sync/lock.rs
> +++ b/rust/kernel/sync/lock.rs
> @@ -111,7 +111,7 @@ pub struct Lock<T: ?Sized, B: Backend> {
>       _pin: PhantomPinned,
>
>       /// The data protected by the lock.
> -    data: UnsafeCell<T>,
> +    pub(crate) data: UnsafeCell<T>,
>   }
>
>   // SAFETY: `Lock` can be transferred across thread boundaries iff the data it protects can.
> diff --git a/rust/kernel/sync/locked_by.rs b/rust/kernel/sync/locked_by.rs
> new file mode 100644
> index 000000000000..191e37d804e5
> --- /dev/null
> +++ b/rust/kernel/sync/locked_by.rs
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! A wrapper for data protected by a lock that does not wrap it.
> +
> +use super::{lock::Backend, lock::Lock};
> +use core::{cell::UnsafeCell, ptr};
> +
> +/// Allows access to some data to be serialised by a lock that does not wrap it.
> +///
> +/// In most cases, data protected by a lock is wrapped by the appropriate lock type, e.g.,
> +/// [`super::Mutex`] or [`super::SpinLock`]. [`LockedBy`] is meant for cases when this is not
> +/// possible. For example, if a container has a lock and some data in the contained elements needs
> +/// to be protected by the same lock.
> +///
> +/// [`LockedBy`] wraps the data in lieu of another locking primitive, and only allows access to it
> +/// when the caller shows evidence that the 'external' lock is locked.
> +///

Maybe add that the `access`/`access_mut` functions panic when the supplied
external value is not the correct one.

> +/// # Examples
> +///
> +/// The following is an example for illustrative purposes: `InnerDirectory::bytes_used` is an
> +/// aggregate of all `InnerFile::bytes_used` and must be kept consistent; so we wrap `InnerFile` in
> +/// a `LockedBy` so that it shares a lock with `InnerDirectory`. This allows us to enforce at
> +/// compile-time that access to `InnerFile` is only granted when an `InnerDirectory` is also
> +/// locked; we enforce at run time that the right `InnerDirectory` is locked.
> +///
> +/// ```
> +/// use kernel::sync::{LockedBy, Mutex};
> +///
> +/// struct InnerFile {
> +///     bytes_used: u64,
> +/// }
> +///
> +/// struct File {
> +///     _ino: u32,
> +///     inner: LockedBy<InnerFile, InnerDirectory>,
> +/// }
> +///
> +/// struct InnerDirectory {
> +///     /// The sum of the bytes used by all files.
> +///     bytes_used: u64,
> +///     _files: Vec<File>,
> +/// }
> +///
> +/// struct Directory {
> +///     _ino: u32,
> +///     inner: Mutex<InnerDirectory>,
> +/// }
> +///
> +/// /// Prints `bytes_used` from both the directory and file.
> +/// fn print_bytes_used(dir: &Directory, file: &File) {
> +///     let guard = dir.inner.lock();
> +///     let inner_file = file.inner.access(&guard);
> +///     pr_info!("{} {}", guard.bytes_used, inner_file.bytes_used);
> +/// }
> +///
> +/// /// Increments `bytes_used` for both the directory and file.
> +/// fn inc_bytes_used(dir: &Directory, file: &File) {
> +///     let mut guard = dir.inner.lock();
> +///     guard.bytes_used += 10;
> +///
> +///     let file_inner = file.inner.access_mut(&mut guard);
> +///     file_inner.bytes_used += 10;
> +/// }
> +///
> +/// /// Creates a new file.
> +/// fn new_file(ino: u32, dir: &Directory) -> File {
> +///     File {
> +///         _ino: ino,
> +///         inner: LockedBy::new(&dir.inner, InnerFile { bytes_used: 0 }),
> +///     }
> +/// }
> +/// ```
> +pub struct LockedBy<T: ?Sized, U: ?Sized> {
> +    owner: *const U,
> +    data: UnsafeCell<T>,
> +}
> +
> +// SAFETY: `LockedBy` can be transferred across thread boundaries iff the data it protects can.
> +unsafe impl<T: ?Sized + Send, U: ?Sized> Send for LockedBy<T, U> {}
> +
> +// SAFETY: `LockedBy` serialises the interior mutability it provides, so it is `Sync` as long as the
> +// data it protects is `Send`.
> +unsafe impl<T: ?Sized + Send, U: ?Sized> Sync for LockedBy<T, U> {}
> +
> +impl<T, U: ?Sized> LockedBy<T, U> {
> +    /// Constructs a new instance of [`LockedBy`].
> +    ///
> +    /// It stores a raw pointer to the owner that is never dereferenced. It is only used to ensure
> +    /// that the right owner is being used to access the protected data. If the owner is freed, the
> +    /// data becomes inaccessible; if another instance of the owner is allocated *on the same
> +    /// memory location*, the data becomes accessible again: none of this affects memory safety
> +    /// because in any case at most one thread (or CPU) can access the protected data at a time.
> +    pub fn new(owner: &Lock<U, impl Backend>, data: T) -> Self {

I think it would be sensible to also do the ZST check here, then it will
fail immediately on construction (but also keep the other location, as it
does not add any runtime cost).

Also, I think you should mention in the documentation that ZSTs are not
supported. And it would be good to have an explaining comment on the
`build_assert!` why we disallow ZSTs here.

> +        Self {
> +            owner: owner.data.get(),
> +            data: UnsafeCell::new(data),
> +        }
> +    }
> +}
> +
> +impl<T: ?Sized, U> LockedBy<T, U> {
> +    /// Returns a reference to the protected data when the caller provides evidence (via a
> +    /// reference) that the owner is locked.

Maybe add a `# Panic` section, also for `access_mut`.

--
Cheers,
Benno

> +    pub fn access<'a>(&'a self, owner: &'a U) -> &'a T {
> +        crate::build_assert!(core::mem::size_of::<U>() > 0);
> +        if !ptr::eq(owner, self.owner) {
> +            panic!("mismatched owners");
> +        }
> +
> +        // SAFETY: `owner` is evidence that the owner is locked.
> +        unsafe { &*self.data.get() }
> +    }
> +
> +    /// Returns a mutable reference to the protected data when the caller provides evidence (via a
> +    /// mutable owner) that the owner is locked mutably.
> +    ///
> +    /// Showing a mutable reference to the owner is sufficient because we know no other references
> +    /// can exist to it.
> +    pub fn access_mut<'a>(&'a self, owner: &'a mut U) -> &'a mut T {
> +        crate::build_assert!(core::mem::size_of::<U>() > 0);
> +        if !ptr::eq(owner, self.owner) {
> +            panic!("mismatched owners");
> +        }
> +
> +        // SAFETY: `owner` is evidence that there is only one reference to the owner.
> +        unsafe { &mut *self.data.get() }
> +    }
> +}
> --
> 2.34.1
>


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 08/13] rust: introduce `ARef`
  2023-04-05 17:51 ` [PATCH v2 08/13] rust: introduce `ARef` Wedson Almeida Filho
@ 2023-04-07 21:59   ` Benno Lossin
  2023-04-08  4:28     ` Wedson Almeida Filho
  0 siblings, 1 reply; 34+ messages in thread
From: Benno Lossin @ 2023-04-07 21:59 UTC (permalink / raw)
  To: Wedson Almeida Filho, rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

On 05.04.23 19:51, Wedson Almeida Filho wrote:
> From: Wedson Almeida Filho <walmeida@microsoft.com>
>
> This is an owned reference to an object that is always ref-counted. This
> is meant to be used in wrappers for C types that have their own ref
> counting functions, for example, tasks, files, inodes, dentries, etc.
>
> Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> ---
> v1 -> v2: No changes
>
>   rust/kernel/types.rs | 107 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 107 insertions(+)
>
> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
> index dbfae9bb97ce..b071730253c7 100644
> --- a/rust/kernel/types.rs
> +++ b/rust/kernel/types.rs
> @@ -6,8 +6,10 @@ use crate::init::{self, PinInit};
>   use alloc::boxed::Box;
>   use core::{
>       cell::UnsafeCell,
> +    marker::PhantomData,
>       mem::MaybeUninit,
>       ops::{Deref, DerefMut},
> +    ptr::NonNull,
>   };
>
>   /// Used to transfer ownership to and from foreign (non-Rust) languages.
> @@ -295,6 +297,111 @@ opaque_init_funcs! {
>       "Rust" manual_init4(arg1: A1, arg2: A2, arg3: A3, arg4: A4);
>   }
>
> +/// Types that are _always_ reference counted.
> +///
> +/// It allows such types to define their own custom ref increment and decrement functions.
> +/// Additionally, it allows users to convert from a shared reference `&T` to an owned reference
> +/// [`ARef<T>`].
> +///
> +/// This is usually implemented by wrappers to existing structures on the C side of the code. For
> +/// Rust code, the recommendation is to use [`Arc`](crate::sync::Arc) to create reference-counted
> +/// instances of a type.
> +///
> +/// # Safety
> +///
> +/// Implementers must ensure that increments to the reference count keep the object alive in memory
> +/// at least until matching decrements are performed.
> +///
> +/// Implementers must also ensure that all instances are reference-counted. (Otherwise they
> +/// won't be able to honour the requirement that [`AlwaysRefCounted::inc_ref`] keep the object
> +/// alive.)
> +pub unsafe trait AlwaysRefCounted {
> +    /// Increments the reference count on the object.
> +    fn inc_ref(&self);
> +
> +    /// Decrements the reference count on the object.
> +    ///
> +    /// Frees the object when the count reaches zero.
> +    ///
> +    /// # Safety
> +    ///
> +    /// Callers must ensure that there was a previous matching increment to the reference count,
> +    /// and that the object is no longer used after its reference count is decremented (as it may
> +    /// result in the object being freed), unless the caller owns another increment on the refcount
> +    /// (e.g., it calls [`AlwaysRefCounted::inc_ref`] twice, then calls
> +    /// [`AlwaysRefCounted::dec_ref`] once).
> +    unsafe fn dec_ref(obj: NonNull<Self>);
> +}
> +
> +/// An owned reference to an always-reference-counted object.
> +///
> +/// The object's reference count is automatically decremented when an instance of [`ARef`] is
> +/// dropped. It is also automatically incremented when a new instance is created via
> +/// [`ARef::clone`].
> +///
> +/// # Invariants
> +///
> +/// The pointer stored in `ptr` is non-null and valid for the lifetime of the [`ARef`] instance. In
> +/// particular, the [`ARef`] instance owns an increment on the underlying object's reference count.
> +pub struct ARef<T: AlwaysRefCounted> {
> +    ptr: NonNull<T>,
> +    _p: PhantomData<T>,
> +}
> +
> +impl<T: AlwaysRefCounted> ARef<T> {
> +    /// Creates a new instance of [`ARef`].
> +    ///
> +    /// It takes over an increment of the reference count on the underlying object.
> +    ///
> +    /// # Safety
> +    ///
> +    /// Callers must ensure that the reference count was incremented at least once, and that they
> +    /// are properly relinquishing one increment. That is, if there is only one increment, callers
> +    /// must not use the underlying object anymore -- it is only safe to do so via the newly
> +    /// created [`ARef`].

I think you should also mention that the pointee at `ptr` must live
at least until this `ARef` decides to decrement the refcount.
Otherwise I would interpret the docs as written to allow you to give
a pointer to the stack and then free the backing storage and then
continue to use the `ARef`.

--
Cheers,
Benno

> +    pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
> +        // INVARIANT: The safety requirements guarantee that the new instance now owns the
> +        // increment on the refcount.
> +        Self {
> +            ptr,
> +            _p: PhantomData,
> +        }
> +    }
> +}
> +
> +impl<T: AlwaysRefCounted> Clone for ARef<T> {
> +    fn clone(&self) -> Self {
> +        self.inc_ref();
> +        // SAFETY: We just incremented the refcount above.
> +        unsafe { Self::from_raw(self.ptr) }
> +    }
> +}
> +
> +impl<T: AlwaysRefCounted> Deref for ARef<T> {
> +    type Target = T;
> +
> +    fn deref(&self) -> &Self::Target {
> +        // SAFETY: The type invariants guarantee that the object is valid.
> +        unsafe { self.ptr.as_ref() }
> +    }
> +}
> +
> +impl<T: AlwaysRefCounted> From<&T> for ARef<T> {
> +    fn from(b: &T) -> Self {
> +        b.inc_ref();
> +        // SAFETY: We just incremented the refcount above.
> +        unsafe { Self::from_raw(NonNull::from(b)) }
> +    }
> +}
> +
> +impl<T: AlwaysRefCounted> Drop for ARef<T> {
> +    fn drop(&mut self) {
> +        // SAFETY: The type invariants guarantee that the `ARef` owns the reference we're about to
> +        // decrement.
> +        unsafe { T::dec_ref(self.ptr) };
> +    }
> +}
> +
>   /// A sum type that always holds either a value of type `L` or `R`.
>   pub enum Either<L, R> {
>       /// Constructs an instance of [`Either`] containing a value of type `L`.
> --
> 2.34.1
>


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 10/13] rust: introduce `current`
  2023-04-05 17:51 ` [PATCH v2 10/13] rust: introduce `current` Wedson Almeida Filho
@ 2023-04-07 22:36   ` Benno Lossin
  2023-04-08  3:54     ` Wedson Almeida Filho
  0 siblings, 1 reply; 34+ messages in thread
From: Benno Lossin @ 2023-04-07 22:36 UTC (permalink / raw)
  To: Wedson Almeida Filho, rust-for-linux
  Cc: Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Ingo Molnar, Peter Zijlstra

On 05.04.23 19:51, Wedson Almeida Filho wrote:
> From: Wedson Almeida Filho <walmeida@microsoft.com>
>
> This allows Rust code to get a reference to the current task without
> having to increment the refcount, but still guaranteeing memory safety.
>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> ---
> v1 -> v2: Make `current` a macro to prevent it from escaping the caller
>
>   rust/helpers.c         |  6 +++
>   rust/kernel/prelude.rs |  2 +
>   rust/kernel/task.rs    | 93 +++++++++++++++++++++++++++++++++++++++++-
>   3 files changed, 100 insertions(+), 1 deletion(-)
>
> diff --git a/rust/helpers.c b/rust/helpers.c
> index 58a194042c86..96441744030e 100644
> --- a/rust/helpers.c
> +++ b/rust/helpers.c
> @@ -100,6 +100,12 @@ bool rust_helper_refcount_dec_and_test(refcount_t *r)
>   }
>   EXPORT_SYMBOL_GPL(rust_helper_refcount_dec_and_test);
>
> +struct task_struct *rust_helper_get_current(void)
> +{
> +	return current;
> +}
> +EXPORT_SYMBOL_GPL(rust_helper_get_current);
> +
>   void rust_helper_get_task_struct(struct task_struct *t)
>   {
>   	get_task_struct(t);
> diff --git a/rust/kernel/prelude.rs b/rust/kernel/prelude.rs
> index fcdc511d2ce8..c28587d68ebc 100644
> --- a/rust/kernel/prelude.rs
> +++ b/rust/kernel/prelude.rs
> @@ -36,3 +36,5 @@ pub use super::error::{code::*, Error, Result};
>   pub use super::{str::CStr, ThisModule};
>
>   pub use super::init::{InPlaceInit, Init, PinInit};
> +
> +pub use super::current;
> diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
> index 8d7a8222990f..468387a5f7eb 100644
> --- a/rust/kernel/task.rs
> +++ b/rust/kernel/task.rs
> @@ -5,7 +5,17 @@
>   //! C header: [`include/linux/sched.h`](../../../../include/linux/sched.h).
>
>   use crate::bindings;
> -use core::{cell::UnsafeCell, ptr};
> +use core::{cell::UnsafeCell, marker::PhantomData, ops::Deref, ptr};
> +
> +/// Returns the currently running task.
> +#[macro_export]
> +macro_rules! current {
> +    () => {
> +        // SAFETY: Deref + addr-of below create a temporary `TaskRef` that cannot outlive the
> +        // caller.
> +        unsafe { &*$crate::task::Task::current() }
> +    };
> +}
>
>   /// Wraps the kernel's `struct task_struct`.
>   ///
> @@ -13,6 +23,42 @@ use core::{cell::UnsafeCell, ptr};
>   ///
>   /// Instances of this type are always ref-counted, that is, a call to `get_task_struct` ensures
>   /// that the allocation remains valid at least until the matching call to `put_task_struct`.
> +///
> +/// # Examples
> +///
> +/// The following is an example of getting the PID of the current thread with zero additional cost
> +/// when compared to the C version:
> +///
> +/// ```
> +/// let pid = current!().pid();
> +/// ```
> +///
> +/// Getting the PID of the current process, also zero additional cost:
> +///
> +/// ```
> +/// let pid = current!().group_leader().pid();
> +/// ```
> +///
> +/// Getting the current task and storing it in some struct. The reference count is automatically
> +/// incremented when creating `State` and decremented when it is dropped:
> +///
> +/// ```
> +/// use kernel::{task::Task, types::ARef};
> +///
> +/// struct State {
> +///     creator: ARef<Task>,
> +///     index: u32,
> +/// }
> +///
> +/// impl State {
> +///     fn new() -> Self {
> +///         Self {
> +///             creator: current!().into(),
> +///             index: 0,
> +///         }
> +///     }
> +/// }
> +/// ```
>   #[repr(transparent)]
>   pub struct Task(pub(crate) UnsafeCell<bindings::task_struct>);
>
> @@ -25,6 +71,24 @@ unsafe impl Sync for Task {}
>   type Pid = bindings::pid_t;
>
>   impl Task {
> +    /// Returns a task reference for the currently executing task/thread.
> +    ///

Add a link to the `current!` macro as a safe version of this function.

> +    /// # Safety
> +    ///
> +    /// Callers must ensure that the returned [`TaskRef`] doesn't outlive the current task/thread.
> +    pub unsafe fn current<'a>() -> TaskRef<'a> {
> +        // SAFETY: Just an FFI call with no additional safety requirements.
> +        let ptr = unsafe { bindings::get_current() };
> +
> +        TaskRef {
> +            // SAFETY: If the current thread is still running, the current task is valid. Given
> +            // that `TaskRef` is not `Send`, we know it cannot be transferred to another thread
> +            // (where it could potentially outlive the caller).
> +            task: unsafe { &*ptr.cast() },
> +            _not_send: PhantomData,
> +        }
> +    }
> +
>       /// Returns the group leader of the given task.
>       pub fn group_leader(&self) -> &Task {
>           // SAFETY: By the type invariant, we know that `self.0` is valid.
> @@ -69,3 +133,30 @@ unsafe impl crate::types::AlwaysRefCounted for Task {
>           unsafe { bindings::put_task_struct(obj.cast().as_ptr()) }
>       }
>   }
> +
> +/// A wrapper for a shared reference to [`Task`] that isn't [`Send`].
> +///
> +/// We make this explicitly not [`Send`] so that we can use it to represent the current thread
> +/// without having to increment/decrement the task's reference count.
> +///
> +/// # Invariants
> +///
> +/// The wrapped [`Task`] remains valid for the lifetime of the object.
> +pub struct TaskRef<'a> {
> +    task: &'a Task,
> +    _not_send: PhantomData<*mut ()>,
> +}
> +
> +impl Deref for TaskRef<'_> {
> +    type Target = Task;
> +
> +    fn deref(&self) -> &Self::Target {
> +        self.task
> +    }
> +}
> +
> +impl From<TaskRef<'_>> for crate::types::ARef<Task> {
> +    fn from(t: TaskRef<'_>) -> Self {
> +        t.deref().into()
> +    }
> +}

Maybe we can hide this struct and return an `impl Deref<Target = Task>`
in `Task::current` instead (it will still be `!Send`)? Users do not
really need to see this implementation detail.

--
Cheers,
Benno

> --
> 2.34.1
>


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 10/13] rust: introduce `current`
  2023-04-07 22:36   ` Benno Lossin
@ 2023-04-08  3:54     ` Wedson Almeida Filho
  0 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-08  3:54 UTC (permalink / raw)
  To: Benno Lossin
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho,
	Ingo Molnar, Peter Zijlstra

On Fri, 7 Apr 2023 at 19:36, Benno Lossin <y86-dev@protonmail.com> wrote:
>
> On 05.04.23 19:51, Wedson Almeida Filho wrote:
> > From: Wedson Almeida Filho <walmeida@microsoft.com>
> >
> > This allows Rust code to get a reference to the current task without
> > having to increment the refcount, but still guaranteeing memory safety.
> >
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> > ---
> > v1 -> v2: Make `current` a macro to prevent it from escaping the caller
> >
> >   rust/helpers.c         |  6 +++
> >   rust/kernel/prelude.rs |  2 +
> >   rust/kernel/task.rs    | 93 +++++++++++++++++++++++++++++++++++++++++-
> >   3 files changed, 100 insertions(+), 1 deletion(-)
> >
> > diff --git a/rust/helpers.c b/rust/helpers.c
> > index 58a194042c86..96441744030e 100644
> > --- a/rust/helpers.c
> > +++ b/rust/helpers.c
> > @@ -100,6 +100,12 @@ bool rust_helper_refcount_dec_and_test(refcount_t *r)
> >   }
> >   EXPORT_SYMBOL_GPL(rust_helper_refcount_dec_and_test);
> >
> > +struct task_struct *rust_helper_get_current(void)
> > +{
> > +     return current;
> > +}
> > +EXPORT_SYMBOL_GPL(rust_helper_get_current);
> > +
> >   void rust_helper_get_task_struct(struct task_struct *t)
> >   {
> >       get_task_struct(t);
> > diff --git a/rust/kernel/prelude.rs b/rust/kernel/prelude.rs
> > index fcdc511d2ce8..c28587d68ebc 100644
> > --- a/rust/kernel/prelude.rs
> > +++ b/rust/kernel/prelude.rs
> > @@ -36,3 +36,5 @@ pub use super::error::{code::*, Error, Result};
> >   pub use super::{str::CStr, ThisModule};
> >
> >   pub use super::init::{InPlaceInit, Init, PinInit};
> > +
> > +pub use super::current;
> > diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
> > index 8d7a8222990f..468387a5f7eb 100644
> > --- a/rust/kernel/task.rs
> > +++ b/rust/kernel/task.rs
> > @@ -5,7 +5,17 @@
> >   //! C header: [`include/linux/sched.h`](../../../../include/linux/sched.h).
> >
> >   use crate::bindings;
> > -use core::{cell::UnsafeCell, ptr};
> > +use core::{cell::UnsafeCell, marker::PhantomData, ops::Deref, ptr};
> > +
> > +/// Returns the currently running task.
> > +#[macro_export]
> > +macro_rules! current {
> > +    () => {
> > +        // SAFETY: Deref + addr-of below create a temporary `TaskRef` that cannot outlive the
> > +        // caller.
> > +        unsafe { &*$crate::task::Task::current() }
> > +    };
> > +}
> >
> >   /// Wraps the kernel's `struct task_struct`.
> >   ///
> > @@ -13,6 +23,42 @@ use core::{cell::UnsafeCell, ptr};
> >   ///
> >   /// Instances of this type are always ref-counted, that is, a call to `get_task_struct` ensures
> >   /// that the allocation remains valid at least until the matching call to `put_task_struct`.
> > +///
> > +/// # Examples
> > +///
> > +/// The following is an example of getting the PID of the current thread with zero additional cost
> > +/// when compared to the C version:
> > +///
> > +/// ```
> > +/// let pid = current!().pid();
> > +/// ```
> > +///
> > +/// Getting the PID of the current process, also zero additional cost:
> > +///
> > +/// ```
> > +/// let pid = current!().group_leader().pid();
> > +/// ```
> > +///
> > +/// Getting the current task and storing it in some struct. The reference count is automatically
> > +/// incremented when creating `State` and decremented when it is dropped:
> > +///
> > +/// ```
> > +/// use kernel::{task::Task, types::ARef};
> > +///
> > +/// struct State {
> > +///     creator: ARef<Task>,
> > +///     index: u32,
> > +/// }
> > +///
> > +/// impl State {
> > +///     fn new() -> Self {
> > +///         Self {
> > +///             creator: current!().into(),
> > +///             index: 0,
> > +///         }
> > +///     }
> > +/// }
> > +/// ```
> >   #[repr(transparent)]
> >   pub struct Task(pub(crate) UnsafeCell<bindings::task_struct>);
> >
> > @@ -25,6 +71,24 @@ unsafe impl Sync for Task {}
> >   type Pid = bindings::pid_t;
> >
> >   impl Task {
> > +    /// Returns a task reference for the currently executing task/thread.
> > +    ///
>
> Add a link to the `current!` macro as a safe version of this function.

Good idea, I'll add it in v3.

> > +    /// # Safety
> > +    ///
> > +    /// Callers must ensure that the returned [`TaskRef`] doesn't outlive the current task/thread.
> > +    pub unsafe fn current<'a>() -> TaskRef<'a> {
> > +        // SAFETY: Just an FFI call with no additional safety requirements.
> > +        let ptr = unsafe { bindings::get_current() };
> > +
> > +        TaskRef {
> > +            // SAFETY: If the current thread is still running, the current task is valid. Given
> > +            // that `TaskRef` is not `Send`, we know it cannot be transferred to another thread
> > +            // (where it could potentially outlive the caller).
> > +            task: unsafe { &*ptr.cast() },
> > +            _not_send: PhantomData,
> > +        }
> > +    }
> > +
> >       /// Returns the group leader of the given task.
> >       pub fn group_leader(&self) -> &Task {
> >           // SAFETY: By the type invariant, we know that `self.0` is valid.
> > @@ -69,3 +133,30 @@ unsafe impl crate::types::AlwaysRefCounted for Task {
> >           unsafe { bindings::put_task_struct(obj.cast().as_ptr()) }
> >       }
> >   }
> > +
> > +/// A wrapper for a shared reference to [`Task`] that isn't [`Send`].
> > +///
> > +/// We make this explicitly not [`Send`] so that we can use it to represent the current thread
> > +/// without having to increment/decrement the task's reference count.
> > +///
> > +/// # Invariants
> > +///
> > +/// The wrapped [`Task`] remains valid for the lifetime of the object.
> > +pub struct TaskRef<'a> {
> > +    task: &'a Task,
> > +    _not_send: PhantomData<*mut ()>,
> > +}
> > +
> > +impl Deref for TaskRef<'_> {
> > +    type Target = Task;
> > +
> > +    fn deref(&self) -> &Self::Target {
> > +        self.task
> > +    }
> > +}
> > +
> > +impl From<TaskRef<'_>> for crate::types::ARef<Task> {
> > +    fn from(t: TaskRef<'_>) -> Self {
> > +        t.deref().into()
> > +    }
> > +}
>
> Maybe we can hide this struct and return an `impl Deref<Target = Task>`
> in `Task::current` instead (it will still be `!Send`)? Users do not
> really need to see this implementation detail.

Hmm, I was a bit concerned with the impl of `From<TaskRef>` for
`ARef<Task>`, but it seems to work. I moved the whole type into
`Task::current` for v3.

Thanks for review!

Cheers,
-Wedson

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 13/13] rust: sync: introduce `LockedBy`
  2023-04-07 21:00   ` Benno Lossin
@ 2023-04-08  4:11     ` Wedson Almeida Filho
  2023-04-08  7:52       ` Benno Lossin
  0 siblings, 1 reply; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-08  4:11 UTC (permalink / raw)
  To: Benno Lossin
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

On Fri, 7 Apr 2023 at 18:00, Benno Lossin <y86-dev@protonmail.com> wrote:
>
> On 05.04.23 19:51, Wedson Almeida Filho wrote:
> > From: Wedson Almeida Filho <walmeida@microsoft.com>
> >
> > This allows us to have data protected by a lock despite not being
> > wrapped by it. Access is granted by providing evidence that the lock is
> > held by the caller.
> >
> > Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> > ---
> > v1 -> v2: Added build_assert to rule out zero-sized types
> >
> >   rust/kernel/sync.rs           |   2 +
> >   rust/kernel/sync/lock.rs      |   2 +-
> >   rust/kernel/sync/locked_by.rs | 128 ++++++++++++++++++++++++++++++++++
> >   3 files changed, 131 insertions(+), 1 deletion(-)
> >   create mode 100644 rust/kernel/sync/locked_by.rs
> >
> > diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
> > index d6dd0e2c1678..f8edb6d0d794 100644
> > --- a/rust/kernel/sync.rs
> > +++ b/rust/kernel/sync.rs
> > @@ -10,10 +10,12 @@ use crate::types::Opaque;
> >   mod arc;
> >   mod condvar;
> >   pub mod lock;
> > +mod locked_by;
> >
> >   pub use arc::{Arc, ArcBorrow, UniqueArc};
> >   pub use condvar::CondVar;
> >   pub use lock::{mutex::Mutex, spinlock::SpinLock};
> > +pub use locked_by::LockedBy;
> >
> >   /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
> >   #[repr(transparent)]
> > diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
> > index f52ba9ab1b70..51c996ca2109 100644
> > --- a/rust/kernel/sync/lock.rs
> > +++ b/rust/kernel/sync/lock.rs
> > @@ -111,7 +111,7 @@ pub struct Lock<T: ?Sized, B: Backend> {
> >       _pin: PhantomPinned,
> >
> >       /// The data protected by the lock.
> > -    data: UnsafeCell<T>,
> > +    pub(crate) data: UnsafeCell<T>,
> >   }
> >
> >   // SAFETY: `Lock` can be transferred across thread boundaries iff the data it protects can.
> > diff --git a/rust/kernel/sync/locked_by.rs b/rust/kernel/sync/locked_by.rs
> > new file mode 100644
> > index 000000000000..191e37d804e5
> > --- /dev/null
> > +++ b/rust/kernel/sync/locked_by.rs
> > @@ -0,0 +1,128 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +//! A wrapper for data protected by a lock that does not wrap it.
> > +
> > +use super::{lock::Backend, lock::Lock};
> > +use core::{cell::UnsafeCell, ptr};
> > +
> > +/// Allows access to some data to be serialised by a lock that does not wrap it.
> > +///
> > +/// In most cases, data protected by a lock is wrapped by the appropriate lock type, e.g.,
> > +/// [`super::Mutex`] or [`super::SpinLock`]. [`LockedBy`] is meant for cases when this is not
> > +/// possible. For example, if a container has a lock and some data in the contained elements needs
> > +/// to be protected by the same lock.
> > +///
> > +/// [`LockedBy`] wraps the data in lieu of another locking primitive, and only allows access to it
> > +/// when the caller shows evidence that the 'external' lock is locked.
> > +///
>
> Maybe add that the `access`/`access_mut` functions panic when the supplied
> external value is not the correct one.

Will do for v3.

> > +/// # Examples
> > +///
> > +/// The following is an example for illustrative purposes: `InnerDirectory::bytes_used` is an
> > +/// aggregate of all `InnerFile::bytes_used` and must be kept consistent; so we wrap `InnerFile` in
> > +/// a `LockedBy` so that it shares a lock with `InnerDirectory`. This allows us to enforce at
> > +/// compile-time that access to `InnerFile` is only granted when an `InnerDirectory` is also
> > +/// locked; we enforce at run time that the right `InnerDirectory` is locked.
> > +///
> > +/// ```
> > +/// use kernel::sync::{LockedBy, Mutex};
> > +///
> > +/// struct InnerFile {
> > +///     bytes_used: u64,
> > +/// }
> > +///
> > +/// struct File {
> > +///     _ino: u32,
> > +///     inner: LockedBy<InnerFile, InnerDirectory>,
> > +/// }
> > +///
> > +/// struct InnerDirectory {
> > +///     /// The sum of the bytes used by all files.
> > +///     bytes_used: u64,
> > +///     _files: Vec<File>,
> > +/// }
> > +///
> > +/// struct Directory {
> > +///     _ino: u32,
> > +///     inner: Mutex<InnerDirectory>,
> > +/// }
> > +///
> > +/// /// Prints `bytes_used` from both the directory and file.
> > +/// fn print_bytes_used(dir: &Directory, file: &File) {
> > +///     let guard = dir.inner.lock();
> > +///     let inner_file = file.inner.access(&guard);
> > +///     pr_info!("{} {}", guard.bytes_used, inner_file.bytes_used);
> > +/// }
> > +///
> > +/// /// Increments `bytes_used` for both the directory and file.
> > +/// fn inc_bytes_used(dir: &Directory, file: &File) {
> > +///     let mut guard = dir.inner.lock();
> > +///     guard.bytes_used += 10;
> > +///
> > +///     let file_inner = file.inner.access_mut(&mut guard);
> > +///     file_inner.bytes_used += 10;
> > +/// }
> > +///
> > +/// /// Creates a new file.
> > +/// fn new_file(ino: u32, dir: &Directory) -> File {
> > +///     File {
> > +///         _ino: ino,
> > +///         inner: LockedBy::new(&dir.inner, InnerFile { bytes_used: 0 }),
> > +///     }
> > +/// }
> > +/// ```
> > +pub struct LockedBy<T: ?Sized, U: ?Sized> {
> > +    owner: *const U,
> > +    data: UnsafeCell<T>,
> > +}
> > +
> > +// SAFETY: `LockedBy` can be transferred across thread boundaries iff the data it protects can.
> > +unsafe impl<T: ?Sized + Send, U: ?Sized> Send for LockedBy<T, U> {}
> > +
> > +// SAFETY: `LockedBy` serialises the interior mutability it provides, so it is `Sync` as long as the
> > +// data it protects is `Send`.
> > +unsafe impl<T: ?Sized + Send, U: ?Sized> Sync for LockedBy<T, U> {}
> > +
> > +impl<T, U: ?Sized> LockedBy<T, U> {
> > +    /// Constructs a new instance of [`LockedBy`].
> > +    ///
> > +    /// It stores a raw pointer to the owner that is never dereferenced. It is only used to ensure
> > +    /// that the right owner is being used to access the protected data. If the owner is freed, the
> > +    /// data becomes inaccessible; if another instance of the owner is allocated *on the same
> > +    /// memory location*, the data becomes accessible again: none of this affects memory safety
> > +    /// because in any case at most one thread (or CPU) can access the protected data at a time.
> > +    pub fn new(owner: &Lock<U, impl Backend>, data: T) -> Self {
>
> I think it would be sensible to also do the ZST check here, then it will
> fail immediately on construction (but also keep the other location, as it
> does not add any runtime cost).

This ZST restriction on `U` applies to `access` and `access_mut`, but
doesn't apply to versions of these functions that work on `Guard`
instances, which we have in the `rust` branch but not here yet. (The
restrictions there are different.) So it doesn't make sense to block
the _creation_ of `LockedBy` instances if `access`/`access_mut` are
never used.

> Also, I think you should mention in the documentation that ZSTs are not
> supported. And it would be good to have an explaining comment on the
> `build_assert!` why we disallow ZSTs here.

I'll add comments in v3 to access/access_mut.

> > +        Self {
> > +            owner: owner.data.get(),
> > +            data: UnsafeCell::new(data),
> > +        }
> > +    }
> > +}
> > +
> > +impl<T: ?Sized, U> LockedBy<T, U> {
> > +    /// Returns a reference to the protected data when the caller provides evidence (via a
> > +    /// reference) that the owner is locked.
>
> Maybe add a `# Panic` section, also for `access_mut`.
>
> --
> Cheers,
> Benno
>
> > +    pub fn access<'a>(&'a self, owner: &'a U) -> &'a T {
> > +        crate::build_assert!(core::mem::size_of::<U>() > 0);
> > +        if !ptr::eq(owner, self.owner) {
> > +            panic!("mismatched owners");
> > +        }
> > +
> > +        // SAFETY: `owner` is evidence that the owner is locked.
> > +        unsafe { &*self.data.get() }
> > +    }
> > +
> > +    /// Returns a mutable reference to the protected data when the caller provides evidence (via a
> > +    /// mutable owner) that the owner is locked mutably.
> > +    ///
> > +    /// Showing a mutable reference to the owner is sufficient because we know no other references
> > +    /// can exist to it.
> > +    pub fn access_mut<'a>(&'a self, owner: &'a mut U) -> &'a mut T {
> > +        crate::build_assert!(core::mem::size_of::<U>() > 0);
> > +        if !ptr::eq(owner, self.owner) {
> > +            panic!("mismatched owners");
> > +        }
> > +
> > +        // SAFETY: `owner` is evidence that there is only one reference to the owner.
> > +        unsafe { &mut *self.data.get() }
> > +    }
> > +}
> > --
> > 2.34.1
> >
>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 08/13] rust: introduce `ARef`
  2023-04-07 21:59   ` Benno Lossin
@ 2023-04-08  4:28     ` Wedson Almeida Filho
  0 siblings, 0 replies; 34+ messages in thread
From: Wedson Almeida Filho @ 2023-04-08  4:28 UTC (permalink / raw)
  To: Benno Lossin
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

On Fri, 7 Apr 2023 at 18:59, Benno Lossin <y86-dev@protonmail.com> wrote:
>
> On 05.04.23 19:51, Wedson Almeida Filho wrote:
> > From: Wedson Almeida Filho <walmeida@microsoft.com>
> >
> > This is an owned reference to an object that is always ref-counted. This
> > is meant to be used in wrappers for C types that have their own ref
> > counting functions, for example, tasks, files, inodes, dentries, etc.
> >
> > Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> > ---
> > v1 -> v2: No changes
> >
> >   rust/kernel/types.rs | 107 +++++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 107 insertions(+)
> >
> > diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
> > index dbfae9bb97ce..b071730253c7 100644
> > --- a/rust/kernel/types.rs
> > +++ b/rust/kernel/types.rs
> > @@ -6,8 +6,10 @@ use crate::init::{self, PinInit};
> >   use alloc::boxed::Box;
> >   use core::{
> >       cell::UnsafeCell,
> > +    marker::PhantomData,
> >       mem::MaybeUninit,
> >       ops::{Deref, DerefMut},
> > +    ptr::NonNull,
> >   };
> >
> >   /// Used to transfer ownership to and from foreign (non-Rust) languages.
> > @@ -295,6 +297,111 @@ opaque_init_funcs! {
> >       "Rust" manual_init4(arg1: A1, arg2: A2, arg3: A3, arg4: A4);
> >   }
> >
> > +/// Types that are _always_ reference counted.
> > +///
> > +/// It allows such types to define their own custom ref increment and decrement functions.
> > +/// Additionally, it allows users to convert from a shared reference `&T` to an owned reference
> > +/// [`ARef<T>`].
> > +///
> > +/// This is usually implemented by wrappers to existing structures on the C side of the code. For
> > +/// Rust code, the recommendation is to use [`Arc`](crate::sync::Arc) to create reference-counted
> > +/// instances of a type.
> > +///
> > +/// # Safety
> > +///
> > +/// Implementers must ensure that increments to the reference count keep the object alive in memory
> > +/// at least until matching decrements are performed.
> > +///
> > +/// Implementers must also ensure that all instances are reference-counted. (Otherwise they
> > +/// won't be able to honour the requirement that [`AlwaysRefCounted::inc_ref`] keep the object
> > +/// alive.)
> > +pub unsafe trait AlwaysRefCounted {
> > +    /// Increments the reference count on the object.
> > +    fn inc_ref(&self);
> > +
> > +    /// Decrements the reference count on the object.
> > +    ///
> > +    /// Frees the object when the count reaches zero.
> > +    ///
> > +    /// # Safety
> > +    ///
> > +    /// Callers must ensure that there was a previous matching increment to the reference count,
> > +    /// and that the object is no longer used after its reference count is decremented (as it may
> > +    /// result in the object being freed), unless the caller owns another increment on the refcount
> > +    /// (e.g., it calls [`AlwaysRefCounted::inc_ref`] twice, then calls
> > +    /// [`AlwaysRefCounted::dec_ref`] once).
> > +    unsafe fn dec_ref(obj: NonNull<Self>);
> > +}
> > +
> > +/// An owned reference to an always-reference-counted object.
> > +///
> > +/// The object's reference count is automatically decremented when an instance of [`ARef`] is
> > +/// dropped. It is also automatically incremented when a new instance is created via
> > +/// [`ARef::clone`].
> > +///
> > +/// # Invariants
> > +///
> > +/// The pointer stored in `ptr` is non-null and valid for the lifetime of the [`ARef`] instance. In
> > +/// particular, the [`ARef`] instance owns an increment on the underlying object's reference count.
> > +pub struct ARef<T: AlwaysRefCounted> {
> > +    ptr: NonNull<T>,
> > +    _p: PhantomData<T>,
> > +}
> > +
> > +impl<T: AlwaysRefCounted> ARef<T> {
> > +    /// Creates a new instance of [`ARef`].
> > +    ///
> > +    /// It takes over an increment of the reference count on the underlying object.
> > +    ///
> > +    /// # Safety
> > +    ///
> > +    /// Callers must ensure that the reference count was incremented at least once, and that they
> > +    /// are properly relinquishing one increment. That is, if there is only one increment, callers
> > +    /// must not use the underlying object anymore -- it is only safe to do so via the newly
> > +    /// created [`ARef`].
>
> I think you should also mention that the pointee at `ptr` must live
> at least until this `ARef` decides to decrement the refcount.
> Otherwise I would interpret the docs as written to allow you to give
> a pointer to the stack and then free the backing storage and then
> continue to use the `ARef`.

Note the bound `T: AlwaysRefCounted`. `AlwaysRefCounted` is unsafe and
has the following requirements:

// Implementers must ensure that increments to the reference count
keep the object alive in memory
// at least until matching decrements are performed.
///
/// Implementers must also ensure that all instances are
reference-counted. (Otherwise they
/// won't be able to honour the requirement that
[`AlwaysRefCounted::inc_ref`] keep the object
/// alive.)

The latter guarantees that _all_ instances are refcounted. While the
former guarantees that you can only free an instance when the refcount
goes to zero.

The safety requirement of the function ensures that the caller is
donating an increment to `ARef`.

So it's ok to allocate from the stack. But you cannot free it
immediately without violating some promise you must abide by for
safety.

>
> --
> Cheers,
> Benno
>
> > +    pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
> > +        // INVARIANT: The safety requirements guarantee that the new instance now owns the
> > +        // increment on the refcount.
> > +        Self {
> > +            ptr,
> > +            _p: PhantomData,
> > +        }
> > +    }
> > +}
> > +
> > +impl<T: AlwaysRefCounted> Clone for ARef<T> {
> > +    fn clone(&self) -> Self {
> > +        self.inc_ref();
> > +        // SAFETY: We just incremented the refcount above.
> > +        unsafe { Self::from_raw(self.ptr) }
> > +    }
> > +}
> > +
> > +impl<T: AlwaysRefCounted> Deref for ARef<T> {
> > +    type Target = T;
> > +
> > +    fn deref(&self) -> &Self::Target {
> > +        // SAFETY: The type invariants guarantee that the object is valid.
> > +        unsafe { self.ptr.as_ref() }
> > +    }
> > +}
> > +
> > +impl<T: AlwaysRefCounted> From<&T> for ARef<T> {
> > +    fn from(b: &T) -> Self {
> > +        b.inc_ref();
> > +        // SAFETY: We just incremented the refcount above.
> > +        unsafe { Self::from_raw(NonNull::from(b)) }
> > +    }
> > +}
> > +
> > +impl<T: AlwaysRefCounted> Drop for ARef<T> {
> > +    fn drop(&mut self) {
> > +        // SAFETY: The type invariants guarantee that the `ARef` owns the reference we're about to
> > +        // decrement.
> > +        unsafe { T::dec_ref(self.ptr) };
> > +    }
> > +}
> > +
> >   /// A sum type that always holds either a value of type `L` or `R`.
> >   pub enum Either<L, R> {
> >       /// Constructs an instance of [`Either`] containing a value of type `L`.
> > --
> > 2.34.1
> >
>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH v2 13/13] rust: sync: introduce `LockedBy`
  2023-04-08  4:11     ` Wedson Almeida Filho
@ 2023-04-08  7:52       ` Benno Lossin
  0 siblings, 0 replies; 34+ messages in thread
From: Benno Lossin @ 2023-04-08  7:52 UTC (permalink / raw)
  To: Wedson Almeida Filho
  Cc: rust-for-linux, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, linux-kernel, Wedson Almeida Filho

On 08.04.23 06:11, Wedson Almeida Filho wrote:
> On Fri, 7 Apr 2023 at 18:00, Benno Lossin <y86-dev@protonmail.com> wrote:
>>
>> On 05.04.23 19:51, Wedson Almeida Filho wrote:
>>> From: Wedson Almeida Filho <walmeida@microsoft.com>
>>>
>>> This allows us to have data protected by a lock despite not being
>>> wrapped by it. Access is granted by providing evidence that the lock is
>>> held by the caller.
>>>
>>> Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
>>> ---
>>> v1 -> v2: Added build_assert to rule out zero-sized types
>>>
>>>    rust/kernel/sync.rs           |   2 +
>>>    rust/kernel/sync/lock.rs      |   2 +-
>>>    rust/kernel/sync/locked_by.rs | 128 ++++++++++++++++++++++++++++++++++
>>>    3 files changed, 131 insertions(+), 1 deletion(-)
>>>    create mode 100644 rust/kernel/sync/locked_by.rs
>>>
>>> diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
>>> index d6dd0e2c1678..f8edb6d0d794 100644
>>> --- a/rust/kernel/sync.rs
>>> +++ b/rust/kernel/sync.rs
>>> @@ -10,10 +10,12 @@ use crate::types::Opaque;
>>>    mod arc;
>>>    mod condvar;
>>>    pub mod lock;
>>> +mod locked_by;
>>>
>>>    pub use arc::{Arc, ArcBorrow, UniqueArc};
>>>    pub use condvar::CondVar;
>>>    pub use lock::{mutex::Mutex, spinlock::SpinLock};
>>> +pub use locked_by::LockedBy;
>>>
>>>    /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
>>>    #[repr(transparent)]
>>> diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
>>> index f52ba9ab1b70..51c996ca2109 100644
>>> --- a/rust/kernel/sync/lock.rs
>>> +++ b/rust/kernel/sync/lock.rs
>>> @@ -111,7 +111,7 @@ pub struct Lock<T: ?Sized, B: Backend> {
>>>        _pin: PhantomPinned,
>>>
>>>        /// The data protected by the lock.
>>> -    data: UnsafeCell<T>,
>>> +    pub(crate) data: UnsafeCell<T>,
>>>    }
>>>
>>>    // SAFETY: `Lock` can be transferred across thread boundaries iff the data it protects can.
>>> diff --git a/rust/kernel/sync/locked_by.rs b/rust/kernel/sync/locked_by.rs
>>> new file mode 100644
>>> index 000000000000..191e37d804e5
>>> --- /dev/null
>>> +++ b/rust/kernel/sync/locked_by.rs
>>> @@ -0,0 +1,128 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +//! A wrapper for data protected by a lock that does not wrap it.
>>> +
>>> +use super::{lock::Backend, lock::Lock};
>>> +use core::{cell::UnsafeCell, ptr};
>>> +
>>> +/// Allows access to some data to be serialised by a lock that does not wrap it.
>>> +///
>>> +/// In most cases, data protected by a lock is wrapped by the appropriate lock type, e.g.,
>>> +/// [`super::Mutex`] or [`super::SpinLock`]. [`LockedBy`] is meant for cases when this is not
>>> +/// possible. For example, if a container has a lock and some data in the contained elements needs
>>> +/// to be protected by the same lock.
>>> +///
>>> +/// [`LockedBy`] wraps the data in lieu of another locking primitive, and only allows access to it
>>> +/// when the caller shows evidence that the 'external' lock is locked.
>>> +///
>>
>> Maybe add that the `access`/`access_mut` functions panic when the supplied
>> external value is not the correct one.
>
> Will do for v3.
>
>>> +/// # Examples
>>> +///
>>> +/// The following is an example for illustrative purposes: `InnerDirectory::bytes_used` is an
>>> +/// aggregate of all `InnerFile::bytes_used` and must be kept consistent; so we wrap `InnerFile` in
>>> +/// a `LockedBy` so that it shares a lock with `InnerDirectory`. This allows us to enforce at
>>> +/// compile-time that access to `InnerFile` is only granted when an `InnerDirectory` is also
>>> +/// locked; we enforce at run time that the right `InnerDirectory` is locked.
>>> +///
>>> +/// ```
>>> +/// use kernel::sync::{LockedBy, Mutex};
>>> +///
>>> +/// struct InnerFile {
>>> +///     bytes_used: u64,
>>> +/// }
>>> +///
>>> +/// struct File {
>>> +///     _ino: u32,
>>> +///     inner: LockedBy<InnerFile, InnerDirectory>,
>>> +/// }
>>> +///
>>> +/// struct InnerDirectory {
>>> +///     /// The sum of the bytes used by all files.
>>> +///     bytes_used: u64,
>>> +///     _files: Vec<File>,
>>> +/// }
>>> +///
>>> +/// struct Directory {
>>> +///     _ino: u32,
>>> +///     inner: Mutex<InnerDirectory>,
>>> +/// }
>>> +///
>>> +/// /// Prints `bytes_used` from both the directory and file.
>>> +/// fn print_bytes_used(dir: &Directory, file: &File) {
>>> +///     let guard = dir.inner.lock();
>>> +///     let inner_file = file.inner.access(&guard);
>>> +///     pr_info!("{} {}", guard.bytes_used, inner_file.bytes_used);
>>> +/// }
>>> +///
>>> +/// /// Increments `bytes_used` for both the directory and file.
>>> +/// fn inc_bytes_used(dir: &Directory, file: &File) {
>>> +///     let mut guard = dir.inner.lock();
>>> +///     guard.bytes_used += 10;
>>> +///
>>> +///     let file_inner = file.inner.access_mut(&mut guard);
>>> +///     file_inner.bytes_used += 10;
>>> +/// }
>>> +///
>>> +/// /// Creates a new file.
>>> +/// fn new_file(ino: u32, dir: &Directory) -> File {
>>> +///     File {
>>> +///         _ino: ino,
>>> +///         inner: LockedBy::new(&dir.inner, InnerFile { bytes_used: 0 }),
>>> +///     }
>>> +/// }
>>> +/// ```
>>> +pub struct LockedBy<T: ?Sized, U: ?Sized> {
>>> +    owner: *const U,
>>> +    data: UnsafeCell<T>,
>>> +}
>>> +
>>> +// SAFETY: `LockedBy` can be transferred across thread boundaries iff the data it protects can.
>>> +unsafe impl<T: ?Sized + Send, U: ?Sized> Send for LockedBy<T, U> {}
>>> +
>>> +// SAFETY: `LockedBy` serialises the interior mutability it provides, so it is `Sync` as long as the
>>> +// data it protects is `Send`.
>>> +unsafe impl<T: ?Sized + Send, U: ?Sized> Sync for LockedBy<T, U> {}
>>> +
>>> +impl<T, U: ?Sized> LockedBy<T, U> {
>>> +    /// Constructs a new instance of [`LockedBy`].
>>> +    ///
>>> +    /// It stores a raw pointer to the owner that is never dereferenced. It is only used to ensure
>>> +    /// that the right owner is being used to access the protected data. If the owner is freed, the
>>> +    /// data becomes inaccessible; if another instance of the owner is allocated *on the same
>>> +    /// memory location*, the data becomes accessible again: none of this affects memory safety
>>> +    /// because in any case at most one thread (or CPU) can access the protected data at a time.
>>> +    pub fn new(owner: &Lock<U, impl Backend>, data: T) -> Self {
>>
>> I think it would be sensible to also do the ZST check here, then it will
>> fail immediately on construction (but also keep the other location, as it
>> does not add any runtime cost).
>
> This ZST restriction on `U` applies to `access` and `access_mut`, but
> doesn't apply to versions of these functions that work on `Guard`
> instances, which we have in the `rust` branch but not here yet. (The
> restrictions there are different.) So it doesn't make sense to block
> the _creation_ of `LockedBy` instances if `access`/`access_mut` are
> never used.

Ah because you can only get a `Guard` safely via a `Lock` and at
the moment, all locks cannot be zero-sized even if the data is.

But if we at some point decide to add a `Backend` with the
`State` being a ZST, then this code becomes unsound.

What about adding a `build_assert!(mem::size_of::<Lock<T, B>>() > 0)`
(you will sadly have to spell out the generic parameter of `Backend`).
I worry that we might not remember all of these details when
we add new locks.

--
Cheers,
Benno

>> Also, I think you should mention in the documentation that ZSTs are not
>> supported. And it would be good to have an explaining comment on the
>> `build_assert!` why we disallow ZSTs here.
>
> I'll add comments in v3 to access/access_mut.
>
>>> +        Self {
>>> +            owner: owner.data.get(),
>>> +            data: UnsafeCell::new(data),
>>> +        }
>>> +    }
>>> +}
>>> +
>>> +impl<T: ?Sized, U> LockedBy<T, U> {
>>> +    /// Returns a reference to the protected data when the caller provides evidence (via a
>>> +    /// reference) that the owner is locked.
>>
>> Maybe add a `# Panic` section, also for `access_mut`.
>>
>> --
>> Cheers,
>> Benno
>>
>>> +    pub fn access<'a>(&'a self, owner: &'a U) -> &'a T {
>>> +        crate::build_assert!(core::mem::size_of::<U>() > 0);
>>> +        if !ptr::eq(owner, self.owner) {
>>> +            panic!("mismatched owners");
>>> +        }
>>> +
>>> +        // SAFETY: `owner` is evidence that the owner is locked.
>>> +        unsafe { &*self.data.get() }
>>> +    }
>>> +
>>> +    /// Returns a mutable reference to the protected data when the caller provides evidence (via a
>>> +    /// mutable owner) that the owner is locked mutably.
>>> +    ///
>>> +    /// Showing a mutable reference to the owner is sufficient because we know no other references
>>> +    /// can exist to it.
>>> +    pub fn access_mut<'a>(&'a self, owner: &'a mut U) -> &'a mut T {
>>> +        crate::build_assert!(core::mem::size_of::<U>() > 0);
>>> +        if !ptr::eq(owner, self.owner) {
>>> +            panic!("mismatched owners");
>>> +        }
>>> +
>>> +        // SAFETY: `owner` is evidence that there is only one reference to the owner.
>>> +        unsafe { &mut *self.data.get() }
>>> +    }
>>> +}
>>> --
>>> 2.34.1
>>>
>>



^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2023-04-08  7:52 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-05 17:50 [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 02/13] rust: sync: introduce `Lock` and `Guard` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 03/13] rust: lock: introduce `Mutex` Wedson Almeida Filho
2023-04-05 18:03   ` Greg KH
2023-04-05 18:04     ` Greg KH
2023-04-05 19:18       ` Peter Zijlstra
2023-04-05 20:21         ` Wedson Almeida Filho
2023-04-05 20:29           ` Peter Zijlstra
2023-04-05 20:40             ` Wedson Almeida Filho
2023-04-05 20:49               ` Peter Zijlstra
2023-04-06  8:38                 ` David Laight
2023-04-06 11:21                   ` Marco Elver
2023-04-06 16:25                     ` Miguel Ojeda
2023-04-06 16:45                 ` Miguel Ojeda
2023-04-05 17:51 ` [PATCH v2 04/13] locking/spinlock: introduce spin_lock_init_with_key Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 05/13] rust: lock: introduce `SpinLock` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 06/13] rust: lock: add support for `Lock::lock_irqsave` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 07/13] rust: lock: implement `IrqSaveBackend` for `SpinLock` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 08/13] rust: introduce `ARef` Wedson Almeida Filho
2023-04-07 21:59   ` Benno Lossin
2023-04-08  4:28     ` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 09/13] rust: add basic `Task` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 10/13] rust: introduce `current` Wedson Almeida Filho
2023-04-07 22:36   ` Benno Lossin
2023-04-08  3:54     ` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 11/13] rust: lock: add `Guard::do_unlocked` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 12/13] rust: sync: introduce `CondVar` Wedson Almeida Filho
2023-04-05 17:51 ` [PATCH v2 13/13] rust: sync: introduce `LockedBy` Wedson Almeida Filho
2023-04-07 21:00   ` Benno Lossin
2023-04-08  4:11     ` Wedson Almeida Filho
2023-04-08  7:52       ` Benno Lossin
2023-04-05 18:00 ` [PATCH v2 01/13] rust: sync: introduce `LockClassKey` Greg KH
2023-04-05 20:05   ` Wedson Almeida Filho
2023-04-05 20:21 ` Gary Guo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).