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

["Benno Lossin" <lossin@kernel.org>]

On Mon Jul 7, 2025 at 3:39 PM CEST, Onur wrote:
> On Mon, 23 Jun 2025 17:14:37 +0200
> "Benno Lossin" <lossin@kernel.org> wrote:
>
>> > We also need to take into consideration that the user want to drop
>> > any lock in the sequence? E.g. the user acquires a, b and c, and
>> > then drop b, and then acquires d. Which I think is possible for
>> > ww_mutex.
>> 
>> Hmm what about adding this to the above idea?:
>> 
>>     impl<'a, Locks> WwActiveCtx<'a, Locks>
>>     where
>>         Locks: Tuple
>>     {
>>         fn custom<L2>(self, action: impl FnOnce(Locks) -> L2) ->
>> WwActiveCtx<'a, L2>; }
>> 
>> Then you can do:
>> 
>>     let (a, c, d) = ctx.begin()
>>         .lock(a)
>>         .lock(b)
>>         .lock(c)
>>         .custom(|(a, _, c)| (a, c))
>>         .lock(d)
>>         .finish();
>
>
> Instead of `begin` and `custom`, why not something like this:
>
> 	let (a, c, d) = ctx.init()
> 	    .lock(a)
>             .lock(b)
>             .lock(c)
>             .unlock(b)
>             .lock(d)
>             .finish();
>
> Instead of `begin`, `init` would be better naming to imply `fini` on the
> C side, and `unlock` instead of `custom` would make the intent clearer
> when dropping locks mid chain.

I don't think that this `unlock` operation will work. How would you
implement it?

> I guess `lock()` is going to use the slow path since it's infallible? It
> might be good to provide a `try_lock` that returns -DEADLOCK
> immediately without blocking when it can't acquire the lock.

I think `lock` would first try the fast path and if it fails, it would
unlock all locks taken before & then re-try the slow path. (if that is
how ww_mutex is usually used, if not, I'd need to see the most common
use-case)

---
Cheers,
Benno