All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: "Onur Özkan" <work@onurozkan.dev>,
	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,
	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: Thu, 4 Dec 2025 09:07:18 +0000	[thread overview]
Message-ID: <aTFPRv2ahM_KA3AB@google.com> (raw)
In-Reply-To: <86E0C8EE-393D-4C6A-9C28-BB036A1FFAD6@collabora.com>

On Wed, Dec 03, 2025 at 02:23:14PM -0300, Daniel Almeida wrote:
> 
> 
> > On 3 Dec 2025, at 10:26, Alice Ryhl <aliceryhl@google.com> wrote:
> > 
> > On Mon, Dec 01, 2025 at 01:28:54PM +0300, Onur Özkan wrote:
> >> 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.
> 
> I don’t think this would work with the from_raw() functions. What class
> would you assign then? I think this is precisely what sparked the current
> solution.

There can be a way to create a type for a C-defined class, and
from_raw() can require that you don't use the same Rust type for
different C classes.

Alice

  reply	other threads:[~2025-12-04  9:07 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
2025-12-04  9:08       ` Alice Ryhl
2025-12-03 17:23     ` Daniel Almeida
2025-12-04  9:07       ` Alice Ryhl [this message]
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=aTFPRv2ahM_KA3AB@google.com \
    --to=aliceryhl@google.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.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 \
    --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 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.