linux-kernel - Re: [PATCH v5 2/3] implement ww_mutex abstraction for the Rust tree

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aFlQ7K_mYYbrG8Cl@Mac.home>
Date: Mon, 23 Jun 2025 06:04:44 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Benno Lossin <lossin@...nel.org>
Cc: Onur Özkan <work@...rozkan.dev>,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
	ojeda@...nel.org, alex.gaynor@...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
Subject: Re: [PATCH v5 2/3] implement ww_mutex abstraction for the Rust tree

On Sun, Jun 22, 2025 at 11:18:24AM +0200, Benno Lossin wrote:
> On Sat Jun 21, 2025 at 8:44 PM CEST, Onur Özkan wrote:
> > Adds Rust bindings for the kernel's `ww_mutex` infrastructure to enable
> > deadlock-free acquisition of multiple related locks.
> >
> > The patch abstracts `ww_mutex.h` header and wraps the existing
> > C `ww_mutex` with three main types:
> >     - `WwClass` for grouping related mutexes
> >     - `WwAcquireCtx` for tracking lock acquisition context
> >     - `WwMutex<T>` for the actual lock
> 
> Going to repeat my question from the previous version:
> 
>     I don't know the design of `struct ww_mutex`, but from the code below I
>     gathered that it has some special error return values that signify that
>     one should release other locks.
>     
>     Did anyone think about making a more Rusty API that would allow one to
>     try to lock multiple mutexes at the same time (in a specified order) and
>     if it fails, it would do the resetting automatically?

But the order may not be known ahead of time, for example say you have
a few:

    pub struct Foo {
        other: Arc<WwMutex<Foo>>,
	data: i32,
    }

you need to get the lock of the current object in order to know what's
the next object to lock.

> 
> I'm not familiar with ww_mutex, so I can't tell if there is something
> good that we could do.
> 

It's not a bad idea when it can apply, but we still need to support the
case where the order is unknown.

Regards,
Boqun