All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Onur Özkan" <work@onurozkan.dev>
To: Lyude Paul <lyude@redhat.com>
Cc: rust-for-linux@vger.kernel.org, lossin@kernel.org,
	ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com,
	gary@garyguo.net, 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, daniel.almeida@collabora.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 4/6] rust: ww_mutex: add Mutex, AcquireCtx and MutexGuard
Date: Fri, 28 Nov 2025 14:37:46 +0300	[thread overview]
Message-ID: <20251128143746.4fc57cfb@nimda> (raw)
In-Reply-To: <80844a3e9f27963592b9453b57f227e8fa5f802b.camel@redhat.com>

On Fri, 21 Nov 2025 16:00:18 -0500
Lyude Paul <lyude@redhat.com> wrote:

> Feedback down below:
> 
> On Sat, 2025-11-01 at 19:10 +0300, Onur Özkan wrote:
> > Implements full locking API (lock, try_lock, slow path,
> > interruptible variants) and integration with kernel bindings.
> > 
> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
> > ---
> >  rust/kernel/sync/lock/ww_mutex.rs             | 276
> > ++++++++++++++++++ rust/kernel/sync/lock/ww_mutex/acquire_ctx.rs |
> > 211 +++++++++++++ 2 files changed, 487 insertions(+)
> >  create mode 100644 rust/kernel/sync/lock/ww_mutex/acquire_ctx.rs
> > 
> > diff --git a/rust/kernel/sync/lock/ww_mutex.rs
> > b/rust/kernel/sync/lock/ww_mutex.rs index
> > 727c51cc73af..2a9c1c20281b 100644 ---
> > a/rust/kernel/sync/lock/ww_mutex.rs +++
> > b/rust/kernel/sync/lock/ww_mutex.rs @@ -1,7 +1,283 @@
> >  // SPDX-License-Identifier: GPL-2.0
> >  
> >  //! Rust abstractions for the kernel's wound-wait locking
> > primitives. +//!
> > +//! It is designed to avoid deadlocks when locking multiple
> > [`Mutex`]es +//! that belong to the same [`Class`]. Each lock
> > acquisition uses an +//! [`AcquireCtx`] to track ordering and
> > ensure forward progress. 
> > +use crate::error::to_result;
> > +use crate::prelude::*;
> > +use crate::types::{NotThreadSafe, Opaque};
> > +use crate::{bindings, container_of};
> > +
> > +use core::cell::UnsafeCell;
> > +use core::marker::PhantomData;
> > +
> > +pub use acquire_ctx::AcquireCtx;
> >  pub use class::Class;
> >  
> > +mod acquire_ctx;
> >  mod class;
> > +
> > +/// A wound-wait (ww) mutex that is powered with deadlock avoidance
> > +/// when acquiring multiple locks of the same [`Class`].
> > +///
> > +/// Each mutex belongs to a [`Class`], which the wound-wait
> > algorithm +/// uses to figure out the order of acquisition and
> > prevent deadlocks. +///
> > +/// # Examples
> > +///
> > +/// ```
> > +/// use kernel::c_str;
> > +/// use kernel::sync::Arc;
> > +/// use kernel::sync::lock::ww_mutex::{AcquireCtx, Class, Mutex};
> > +/// use pin_init::stack_pin_init;
> > +///
> > +/// stack_pin_init!(let class =
> > Class::new_wound_wait(c_str!("some_class"))); +/// let mutex =
> > Arc::pin_init(Mutex::new(42, &class), GFP_KERNEL)?; +///
> > +/// let ctx = KBox::pin_init(AcquireCtx::new(&class), GFP_KERNEL)?;
> > +///
> > +/// // SAFETY: Both `ctx` and `mutex` uses the same class.
> > +/// let guard = unsafe { ctx.lock(&mutex)? };
> > +/// assert_eq!(*guard, 42);
> > +///
> > +/// # Ok::<(), Error>(())
> > +/// ```
> > +#[pin_data]
> 
> You're missing a #[repr(C)] here, because… (cont. down below)
> 
> > +pub struct Mutex<'a, T: ?Sized> {
> > +    #[pin]
> > +    inner: Opaque<bindings::ww_mutex>,
> > +    _p: PhantomData<&'a Class>,
> 
> This should be at the bottom of the class
> 
> > +    data: UnsafeCell<T>,
> > +}
> > +
> > +// SAFETY: `Mutex` can be sent to another thread if the protected
> > +// data `T` can be.
> > +unsafe impl<T: ?Sized + Send> Send for Mutex<'_, T> {}
> > +
> > +// SAFETY: `Mutex` can be shared across threads if the protected
> > +// data `T` can be.
> > +unsafe impl<T: ?Sized + Send + Sync> Sync for Mutex<'_, T> {}
> 
> Looks like there's a funny pitfall here! According to Alice Rhyl (see
> the convo we had in zulip), for this to actually be safe we need to
> add an empty Drop implementation to Mutex to ensure the compiler
> doesn't actually allow it to be dropped after the lock class. So
> would be good to add that + a comment of why it's needed
> 

Mutex cannot live longer than the Class it includes. Which means this
case (compiler dropping Mutex because Class was dropped) can't ever
happen. Or, am I missing something here?

[...]
> > +}
> > +
> > +#[pinned_drop]
> > +impl PinnedDrop for AcquireCtx<'_> {
> > +    fn drop(self: Pin<&mut Self>) {
> > +        // SAFETY: Given the lifetime bounds we know no locks are
> > held,
> > +        // so calling `ww_acquire_fini` is safe.
> > +        unsafe { bindings::ww_acquire_fini(self.inner.get()) };
> > +    }
> > +}
> 

-Onur

  parent reply	other threads:[~2025-11-28 11:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-01 16:10 [PATCH v7 0/6] rust: add `ww_mutex` support Onur Özkan
2025-11-01 16:10 ` [PATCH v7 1/6] rust: add C wrappers for ww_mutex inline functions Onur Özkan
2025-11-21 19:08   ` Lyude Paul
2025-11-25 15:53   ` Daniel Almeida
2025-11-01 16:10 ` [PATCH v7 2/6] rust: implement `Class` for ww_class support Onur Özkan
2025-11-21 19:15   ` Lyude Paul
2025-11-27  8:57     ` Onur Özkan
2025-11-25 16:12   ` Daniel Almeida
2025-11-01 16:10 ` [PATCH v7 3/6] rust: error: add EDEADLK Onur Özkan
2025-11-21 19:49   ` Lyude Paul
2025-11-25 16:13   ` Daniel Almeida
2025-11-01 16:10 ` [PATCH v7 4/6] rust: ww_mutex: add Mutex, AcquireCtx and MutexGuard Onur Özkan
2025-11-21 21:00   ` Lyude Paul
2025-11-27  9:24     ` Onur Özkan
2025-11-28 11:37     ` Onur Özkan [this message]
2025-11-25 18:32   ` Daniel Almeida
2025-11-25 18:59     ` Onur Özkan
2025-11-01 16:10 ` [PATCH v7 5/6] rust: ww_mutex: implement LockSet Onur Özkan
2025-11-21 22:34   ` Lyude Paul
2025-11-24 15:49     ` Onur Özkan
2025-11-25 19:01       ` Daniel Almeida
2025-11-25 20:08         ` Onur Özkan
2025-11-25 21:35       ` Lyude Paul
2025-11-25 21:47         ` Daniel Almeida
2025-11-25 22:14           ` Lyude Paul
2025-11-27 10:16         ` Onur Özkan
2025-11-27 13:46           ` Daniel Almeida
2025-11-01 16:10 ` [PATCH v7 6/6] rust: add test coverage for ww_mutex implementation Onur Özkan
2025-11-10  5:28 ` [PATCH v7 0/6] rust: add `ww_mutex` support Onur Özkan

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=20251128143746.4fc57cfb@nimda \
    --to=work@onurozkan.dev \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --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=lyude@redhat.com \
    --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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.