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] [day] [month] [year] [list]
Message-Id: <ECC0425A-8B18-4626-8EA8-2F843C45E0A1@collabora.com>
Date: Thu, 27 Nov 2025 10:46:11 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Onur Özkan <work@...rozkan.dev>
Cc: Lyude Paul <lyude@...hat.com>,
 rust-for-linux@...r.kernel.org,
 lossin@...nel.org,
 ojeda@...nel.org,
 alex.gaynor@...il.com,
 boqun.feng@...il.com,
 gary@...yguo.net,
 a.hindborg@...nel.org,
 aliceryhl@...gle.com,
 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,
 bjorn3_gh@...tonmail.com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 5/6] rust: ww_mutex: implement LockSet



> On 27 Nov 2025, at 07:16, Onur Özkan <work@...rozkan.dev> wrote:
> 
> On Tue, 25 Nov 2025 16:35:21 -0500
> Lyude Paul <lyude@...hat.com> wrote:
> 
>> On Mon, 2025-11-24 at 18:49 +0300, Onur Özkan wrote:
>>>> 
>>>> 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 would be fine with this, and think this is definitely the right way
>> to go
>> 
> 
> It would be great to reach a consensus on this (whether we should send a
> patch to the C side or instead pass the Class to the from_raw functions
> without modifying the C code).
> 
> -Onur 
> 

+1 from me on changing the C side, Onur.

— Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ