linux-kernel - Re: [PATCH v5 0/3] rust: add `ww

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: <20250724165351.509cff53@nimda.home>
Date: Thu, 24 Jul 2025 16:53:51 +0300
From: Onur Özkan <work@...rozkan.dev>
To: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Cc: ojeda@...nel.org, alex.gaynor@...il.com, boqun.feng@...il.com,
 gary@...yguo.net, lossin@...nel.org, 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, Lyude <thatslyude@...il.com>
Subject: Re: [PATCH v5 0/3] rust: add `ww_mutex` support

Hi again,

Just finished going over the C-side use of `ww_mutex` today and I
wanted to share some notes and thoughts based on that.

To get the full context, you might want to take a look at this thread
[1].

- The first note I took is that we shouldn't allow locking without
`WwAcquireCtx` (which is currently possible in v5). As explained in
ww_mutex documentation [2], this basically turns it into a regular
mutex and you don't get benefits of `ww_mutex`.

 From what I have seen on the C side, there is no real use-case for
 this. It doesn't make much sense to use `ww_mutex` just for
 single-locking scenarios. Unless a specific use-case comes up, I think
 we shouldn't support using it that way. I am planning to move the
 `lock*` functions under `impl WwAcquireCtx` (as we discussed in [1]),
 which will make `WwAcquireCtx` required by design and also simplify
 the implementation a lot.

- The second note is about how EDEADLK is handled. On the C side, it
looks like some code paths may not release all the previously locked
mutexes or have a special/custom logic when locking returns EDEADLK
(see [3]). So, handling EDEADLK automatically (pointed
in [1]) can be quite useful for most cases, but that could also be a
limitation in certain scenarios.

 I was thinking we could provide an alternative version of each `lock*`
 function that accepts a closure which is called on the EDEADLK error.
 This way, we can support both auto-release locks and custom logic for
 handling EDEADLK scenarios.

 Something like this (just a dummy code for demonstration):

    ctx.lock_and_handle_edeadlk(|active_locks| {
        // user-defined handling here
    });

 That would let users handle the situation however they want if they
 need to.

Would love to hear your thoughts or suggestions on any of this.

[1]: https://lore.kernel.org/all/DATYHYJVPL3L.3NLMH7PPHYU9@kernel.org/#t
[2]:
https://www.kernel.org/doc/Documentation/locking/ww-mutex-design.txt
[3]:
https://github.com/torvalds/linux/blob/25fae0b93d1d7/drivers/gpu/drm/drm_modeset_lock.c#L326-L329

Regards,
Onur