From: Boqun Feng <boqun.feng@gmail.com>
To: "Onur Özkan" <work@onurozkan.dev>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
ojeda@kernel.org, alex.gaynor@gmail.com, gary@garyguo.net,
lossin@kernel.org, a.hindborg@kernel.org, aliceryhl@google.com,
tmgross@umich.edu, dakr@kernel.org, peterz@infradead.org,
mingo@redhat.com, will@kernel.org, longman@redhat.com,
felipe_life@live.com, daniel@sedlak.dev,
bjorn3_gh@protonmail.com
Subject: Re: [PATCH v5 2/3] implement ww_mutex abstraction for the Rust tree
Date: Mon, 23 Jun 2025 06:26:14 -0700 [thread overview]
Message-ID: <aFlV9ky2RKrYnrJX@Mac.home> (raw)
In-Reply-To: <20250621184454.8354-3-work@onurozkan.dev>
On Sat, Jun 21, 2025 at 09:44:53PM +0300, Onur Özkan wrote:
[...]
> +#[pin_data(PinnedDrop)]
> +pub struct WwAcquireCtx<'a> {
> + #[pin]
> + inner: Opaque<bindings::ww_acquire_ctx>,
> + _p: PhantomData<&'a WwClass>,
> +}
> +
> +// SAFETY: Used in controlled ways during lock acquisition. No race risk.
> +unsafe impl Sync for WwAcquireCtx<'_> {}
> +// SAFETY: Doesn't rely on thread-local state. Safe to move between threads.
> +unsafe impl Send for WwAcquireCtx<'_> {}
> +
I don't think `WwAcquireCtx` is `Send`, if you look at C code when
LOCKDEP is enabled, `ww_acquire_init()` calls a few `mutex_acquire()`
and expects `ww_acquire_fini()` to call the corresponding
`mutex_release()`, and these two have to be on the same task. Also I
don't think there is a need for sending `WwAcquireCtx` to another
thread.
Besides, the `Sync` of `WwAcquireCtx` also doesn't make sense, I would
drop it if there is no real usage for now.
> +impl<'ctx> WwAcquireCtx<'ctx> {
> + /// Initializes `Self` with calling C side `ww_acquire_init` inside.
> + pub fn new<'class: 'ctx>(ww_class: &'class WwClass) -> impl PinInit<Self> {
> + let raw_ptr = ww_class.inner.get();
> + pin_init!(WwAcquireCtx {
> + inner <- Opaque::ffi_init(|slot: *mut bindings::ww_acquire_ctx| {
> + // SAFETY: The caller guarantees that `ww_class` remains valid.
> + unsafe { bindings::ww_acquire_init(slot, raw_ptr) }
> + }),
> + _p: PhantomData
> + })
> + }
> +
> + /// Marks the end of the acquire phase with C side `ww_acquire_done`.
> + ///
> + /// After calling this function, no more mutexes can be acquired with this context.
> + pub fn done(self: Pin<&mut Self>) {
> + // SAFETY: The context is pinned and valid.
> + unsafe { bindings::ww_acquire_done(self.inner.get()) };
> + }
> +
> + /// Returns a raw pointer to the inner `ww_acquire_ctx`.
> + fn as_ptr(&self) -> *mut bindings::ww_acquire_ctx {
> + self.inner.get()
> + }
> +}
> +
> +#[pinned_drop]
> +impl PinnedDrop for WwAcquireCtx<'_> {
> + fn drop(self: Pin<&mut Self>) {
> + // SAFETY: The context is being dropped and is pinned.
> + unsafe { bindings::ww_acquire_fini(self.inner.get()) };
> + }
> +}
> +
[...]
> +#[pin_data]
> +pub struct WwMutex<'a, T: ?Sized> {
> + _p: PhantomData<&'a WwClass>,
> + #[pin]
> + mutex: Opaque<bindings::ww_mutex>,
> + data: UnsafeCell<T>,
> +}
> +
> +// SAFETY: [`WwMutex`] can be shared between threads.
> +unsafe impl<T: ?Sized + Send> Send for WwMutex<'_, T> {}
> +// SAFETY: [`WwMutex`] can be safely accessed from multiple threads concurrently.
> +unsafe impl<T: ?Sized + Sync> Sync for WwMutex<'_, T> {}
I believe this requires `T` being `Send` as well, because if `&WwMutex`
is shared between threads, that means any thread can access `&mut T`
when the lock acquired.
> +
> +impl<'ww_class, T> WwMutex<'ww_class, T> {
> + /// Creates `Self` with calling `ww_mutex_init` inside.
> + pub fn new(t: T, ww_class: &'ww_class WwClass) -> impl PinInit<Self> {
> + let raw_ptr = ww_class.inner.get();
> + pin_init!(WwMutex {
> + mutex <- Opaque::ffi_init(|slot: *mut bindings::ww_mutex| {
> + // SAFETY: The caller guarantees that `ww_class` remains valid.
> + unsafe { bindings::ww_mutex_init(slot, raw_ptr) }
> + }),
> + data: UnsafeCell::new(t),
> + _p: PhantomData,
> + })
> + }
> +}
> +
[...]
> + /// Checks if the mutex is currently locked.
> + pub fn is_locked(&self) -> bool {
Did I miss a reply from you regarding:
https://lore.kernel.org/rust-for-linux/aFReIdlPPg4MmaYX@tardis.local/
no public is_lock() please. Do an assert_is_locked() instead. We need to
avoid users from abusing this.
> + // SAFETY: The mutex is pinned and valid.
> + unsafe { bindings::ww_mutex_is_locked(self.mutex.get()) }
> + }
> +
> + /// Returns a raw pointer to the inner mutex.
> + fn as_ptr(&self) -> *mut bindings::ww_mutex {
> + self.mutex.get()
> + }
> +}
> +
> +/// A guard that provides exclusive access to the data protected
> +/// by a [`WwMutex`].
> +///
> +/// # Invariants
> +///
> +/// The guard holds an exclusive lock on the associated [`WwMutex`]. The lock is held
> +/// for the entire lifetime of this guard and is automatically released when the
> +/// guard is dropped.
> +#[must_use = "the lock unlocks immediately when the guard is unused"]
> +pub struct WwMutexGuard<'a, T: ?Sized> {
> + mutex: &'a WwMutex<'a, T>,
> + _not_send: NotThreadSafe,
> +}
> +
> +// SAFETY: [`WwMutexGuard`] can be transferred across thread boundaries if the data can.
> +unsafe impl<T: ?Sized + Send> Send for WwMutexGuard<'_, T> {}
Nope, ww_mutex is still a mutex, you cannot acquire the lock in one task
and release the lock on another task.
> +
> +// SAFETY: [`WwMutexGuard`] can be shared between threads if the data can.
> +unsafe impl<T: ?Sized + Send + Sync> Sync for WwMutexGuard<'_, T> {}
You don't need the `Send` here? A `&WwMutexGuard` doesn't provide the
access to `&mut T`, so being `Sync` suffices.
Regards,
Boqun
> +
> +impl<'a, T: ?Sized> WwMutexGuard<'a, T> {
> + /// Creates a new guard for a locked mutex.
> + fn new(mutex: &'a WwMutex<'a, T>) -> Self {
> + Self {
> + mutex,
> + _not_send: NotThreadSafe,
> + }
> + }
> +}
> +
> +impl<T: ?Sized> core::ops::Deref for WwMutexGuard<'_, T> {
> + type Target = T;
> +
> + fn deref(&self) -> &Self::Target {
> + // SAFETY: We hold the lock, so we have exclusive access.
> + unsafe { &*self.mutex.data.get() }
> + }
> +}
> +
> +impl<T: ?Sized> core::ops::DerefMut for WwMutexGuard<'_, T> {
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + // SAFETY: We hold the lock, so we have exclusive access.
> + unsafe { &mut *self.mutex.data.get() }
> + }
> +}
> +
> +impl<T: ?Sized> Drop for WwMutexGuard<'_, T> {
> + fn drop(&mut self) {
> + // SAFETY: We hold the lock and are about to release it.
> + unsafe { bindings::ww_mutex_unlock(self.mutex.as_ptr()) };
> + }
> +}
> --
> 2.49.0
>
next prev parent reply other threads:[~2025-06-23 13:26 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-21 18:44 [PATCH v5 0/3] rust: add `ww_mutex` support Onur Özkan
2025-06-21 18:44 ` [PATCH v5 1/3] rust: add C wrappers for `ww_mutex` inline functions Onur Özkan
2025-06-21 18:44 ` [PATCH v5 2/3] implement ww_mutex abstraction for the Rust tree Onur Özkan
2025-06-22 9:18 ` Benno Lossin
2025-06-23 13:04 ` Boqun Feng
2025-06-23 13:44 ` Benno Lossin
2025-06-23 14:47 ` Boqun Feng
2025-06-23 15:14 ` Benno Lossin
2025-06-23 17:11 ` Boqun Feng
2025-06-23 23:22 ` Benno Lossin
2025-06-24 5:34 ` Onur
2025-06-24 8:20 ` Benno Lossin
2025-06-24 12:31 ` Onur
2025-06-24 12:48 ` Benno Lossin
2025-07-07 13:39 ` Onur
2025-07-07 15:31 ` Benno Lossin
2025-07-07 18:06 ` Onur
2025-07-07 19:48 ` Benno Lossin
2025-07-08 14:21 ` Onur
2025-08-01 21:22 ` Daniel Almeida
2025-08-02 10:42 ` Benno Lossin
2025-08-02 13:41 ` Miguel Ojeda
2025-08-02 14:15 ` Daniel Almeida
2025-08-02 20:58 ` Benno Lossin
2025-08-05 15:18 ` Daniel Almeida
2025-08-05 9:08 ` Onur Özkan
2025-08-05 12:41 ` Daniel Almeida
2025-08-05 13:50 ` Onur Özkan
2025-06-23 11:51 ` Alice Ryhl
2025-06-23 13:26 ` Boqun Feng [this message]
2025-06-23 18:17 ` Onur
2025-06-23 21:54 ` Boqun Feng
2025-06-21 18:44 ` [PATCH v5 3/3] add KUnit coverage on Rust `ww_mutex` implementation Onur Özkan
2025-06-22 9:16 ` [PATCH v5 0/3] rust: add `ww_mutex` support Benno Lossin
2025-07-24 13:53 ` Onur Özkan
2025-07-29 17:15 ` Benno Lossin
2025-07-30 10:24 ` Onur Özkan
2025-07-30 10:55 ` Benno Lossin
2025-08-05 16:22 ` Lyude Paul
2025-08-05 17:56 ` Daniel Almeida
2025-08-06 5:57 ` Onur Özkan
2025-08-06 17:37 ` Lyude Paul
2025-08-06 19:30 ` Benno Lossin
2025-08-14 11:13 ` Onur Özkan
2025-08-14 12:38 ` Daniel Almeida
2025-08-14 15:56 ` Onur
2025-08-14 18:22 ` Daniel Almeida
2025-08-18 12:56 ` Onur Özkan
2025-09-01 10:05 ` Onur Özkan
2025-09-01 12:28 ` Daniel Almeida
2025-09-02 16:53 ` Onur
2025-09-03 6:24 ` Onur
2025-09-03 13:04 ` Daniel Almeida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aFlV9ky2RKrYnrJX@Mac.home \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=dakr@kernel.org \
--cc=daniel@sedlak.dev \
--cc=felipe_life@live.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=lossin@kernel.org \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=will@kernel.org \
--cc=work@onurozkan.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).