From: "Onur Özkan" <work@onurozkan.dev>
To: Alice Ryhl <aliceryhl@google.com>
Cc: rust-for-linux@vger.kernel.org, lossin@kernel.org,
lyude@redhat.com, ojeda@kernel.org, alex.gaynor@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net, a.hindborg@kernel.org,
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,
daniel.almeida@collabora.com, thomas.hellstrom@linux.intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 5/6] rust: ww_mutex: add Mutex, AcquireCtx and MutexGuard
Date: Wed, 3 Dec 2025 19:02:30 +0300 [thread overview]
Message-ID: <20251203190230.077abd3c@nimda> (raw)
In-Reply-To: <aTA6f8gK60h6qaHs@google.com>
On Wed, 3 Dec 2025 13:26:23 +0000
Alice Ryhl <aliceryhl@google.com> wrote:
> On Mon, Dec 01, 2025 at 01:28:54PM +0300, Onur Özkan wrote:
> > Covers the entire low-level locking API (lock, try_lock,
> > slow path, interruptible variants) and integration with
> > kernel bindings.
> >
> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
>
> > +impl<'class> Mutex<'class, ()> {
> > + /// Creates a [`Mutex`] from a raw pointer.
> > + ///
> > + /// This function is intended for interoperability with C code.
> > + ///
> > + /// # Safety
> > + ///
> > + /// The caller must ensure that `ptr` is a valid pointer to a
> > `ww_mutex`
> > + /// and that it remains valid for the lifetime `'a`.
> > + pub unsafe fn from_raw<'a>(ptr: *mut bindings::ww_mutex) ->
> > &'a Self {
>
> Should also require that the class is valid for the duration of
> 'class.
>
> > +/// Internal helper that unifies the different locking kinds.
> > +///
> > +/// Returns [`EINVAL`] if the [`Mutex`] has a different [`Class`].
> > +fn lock_common<'a, T: ?Sized>(
> > + mutex: &'a Mutex<'a, T>,
> > + ctx: Option<&AcquireCtx<'_>>,
> > + kind: LockKind,
> > +) -> Result<MutexGuard<'a, T>> {
> > + let mutex_ptr = mutex.inner.get();
> > +
> > + let ctx_ptr = match ctx {
> > + Some(acquire_ctx) => {
> > + let ctx_ptr = acquire_ctx.inner.get();
> > +
> > + // SAFETY: `ctx_ptr` is a valid pointer for the entire
> > + // lifetime of `ctx`.
> > + let ctx_class = unsafe { (*ctx_ptr).ww_class };
> > +
> > + // SAFETY: `mutex_ptr` is a valid pointer for the
> > entire
> > + // lifetime of `mutex`.
> > + let mutex_class = unsafe { (*mutex_ptr).ww_class };
> > +
> > + // `ctx` and `mutex` must use the same class.
> > + if ctx_class != mutex_class {
> > + return Err(EINVAL);
> > + }
>
> Hmm, this originates from the previous conversation:
>
> https://lore.kernel.org/all/20251124184928.30b8bbaf@nimda/
> >>> + /// // SAFETY: Both `lock_set` and `mutex1` uses the
> >>> same class.
> >>> + /// unsafe { lock_set.lock(&mutex1)? };
> >>> + ///
> >>> + /// // SAFETY: Both `lock_set` and `mutex2` uses the
> >>> same class.
> >>> + /// unsafe { lock_set.lock(&mutex2)? };
> >>
> >> I wonder if there's some way we can get rid of the safety contract
> >> here and verify this at compile time, it would be a shame if every
> >> single lock invocation needed to be unsafe.
> >>
> >
> > Yeah :(. We could get rid of them easily by keeping the class that
> > was passed to the constructor functions but that becomes a problem
> > for the from_raw implementations.
> >
> > I think the best solution would be to expose ww_class type from
> > ww_acquire_ctx and ww_mutex unconditionally (right now it depends on
> > DEBUG_WW_MUTEXES). That way we can just access the class and verify
> > that the mutex and acquire_ctx classes match.
> >
> > What do you think? I can submit a patch for the C-side
> > implementation. It should be straightforward and shouldn't have any
> > runtime impact.
>
> I think there is a better solution. We can create a different type for
> every single class, like how rust/kernel/sync/lock/global.rs creates a
> different type for every single mutex. Then, you know that the classes
> are the same since the class is part of the type.
>
> Alice
You can have same types but different memory addresses and that would
break the ww_mutex logic we are trying to solve.
-Onur
next prev parent reply other threads:[~2025-12-03 16:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 10:28 [PATCH v8 0/6] rust: add ww_mutex support Onur Özkan
2025-12-01 10:28 ` [PATCH v8 1/6] rust: add C wrappers for ww_mutex inline functions Onur Özkan
2025-12-02 17:38 ` Daniel Almeida
2025-12-15 13:06 ` Gary Guo
2025-12-01 10:28 ` [PATCH v8 2/6] ww_mutex: add `ww_class` field unconditionally Onur Özkan
2025-12-02 17:42 ` Daniel Almeida
2025-12-01 10:28 ` [PATCH v8 3/6] rust: error: add EDEADLK Onur Özkan
2025-12-02 17:43 ` Daniel Almeida
2025-12-01 10:28 ` [PATCH v8 4/6] rust: implement Class for ww_class support Onur Özkan
2025-12-02 17:59 ` Daniel Almeida
2025-12-25 10:00 ` Onur Özkan
2025-12-03 13:10 ` Alice Ryhl
2025-12-03 16:06 ` Onur Özkan
2025-12-01 10:28 ` [PATCH v8 5/6] rust: ww_mutex: add Mutex, AcquireCtx and MutexGuard Onur Özkan
2025-12-02 1:49 ` kernel test robot
2025-12-02 10:20 ` Onur Özkan
2025-12-02 18:29 ` Daniel Almeida
2025-12-03 15:49 ` Onur Özkan
2025-12-03 13:26 ` Alice Ryhl
2025-12-03 16:02 ` Onur Özkan [this message]
2025-12-04 9:08 ` Alice Ryhl
2025-12-03 17:23 ` Daniel Almeida
2025-12-04 9:07 ` Alice Ryhl
2025-12-04 13:26 ` Daniel Almeida
2025-12-04 13:33 ` Alice Ryhl
2025-12-15 9:10 ` Onur Özkan
2025-12-17 8:54 ` Daniel Almeida
2025-12-01 10:28 ` [PATCH v8 6/6] rust: ww_mutex: implement LockSet 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=20251203190230.077abd3c@nimda \
--to=work@onurozkan.dev \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.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=thomas.hellstrom@linux.intel.com \
--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.