Re: [PATCH v5 0/3] rust: add `ww_mutex` support

[Onur Özkan]

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@xxxxxxxxxx/#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