linux-kernel - Re: [PATCH v8 5/6] rust: ww_mutex: add Mutex, AcquireCtx and MutexGuard

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1879F44-A852-439A-966D-F074AE48E19C@collabora.com>
Date: Thu, 4 Dec 2025 07:26:25 -0600
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Onur Özkan <work@...rozkan.dev>,
 rust-for-linux@...r.kernel.org,
 lossin@...nel.org,
 lyude@...hat.com,
 ojeda@...nel.org,
 alex.gaynor@...il.com,
 boqun.feng@...il.com,
 gary@...yguo.net,
 a.hindborg@...nel.org,
 tmgross@...ch.edu,
 dakr@...nel.org,
 peterz@...radead.org,
 mingo@...hat.com,
 will@...nel.org,
 longman@...hat.com,
 felipe_life@...e.com,
 daniel@...lak.dev,
 thomas.hellstrom@...ux.intel.com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 5/6] rust: ww_mutex: add Mutex, AcquireCtx and
 MutexGuard



> On 4 Dec 2025, at 03:07, Alice Ryhl <aliceryhl@...gle.com> wrote:
> 
> On Wed, Dec 03, 2025 at 02:23:14PM -0300, Daniel Almeida wrote:
>> 
>> 
>>> On 3 Dec 2025, at 10:26, Alice Ryhl <aliceryhl@...gle.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

That’s the problem, if we don’t have patch 2, we don’t know the class.

What you’re suggesting seems unimplementable to me at first. Otherwise, can
you expand some more?

— Daniel

> from_raw() can require that you don't use the same Rust type for
> different C classes.
> 
> Alice