Re: [PATCH v2 3/4] test-ww_mutex: Handle transient -EDEADLK in test_cycle_work

> On 29 Jul 2026, at 02:03, John Stultz <[email protected]> wrote:
> 
> On Mon, Jul 13, 2026 at 9:37 AM Håkon Bugge <[email protected]> wrote:
> >
> > There is a timing issue in test_cycle_work(), in the sense that
> > acquiring *a_mutex* after deadlock has been detected on the *b_mutex*,
> > may not succeed immediately. This may lead to false negatives, which
> > shows up in the log as:
> >
> > cyclic deadlock not resolved, ret[77/93] = -35
> >
> > We re-factor the inner part test_cycle_work(), where we loop a few
> > times attempting to acquire the mutexes in BAAB order. If the first A
> > succeeds or the last B succeeds, we break out of the loop.
> >
> > Fixes: d1b42b800e5d ("locking/ww_mutex: Add kselftests for resolving ww_mutex cyclic deadlocks")
> > Fixes: e4a02ed2aaf4 ("locking/ww_mutex: Fix runtime warning in the WW mutex selftest")
> > Signed-off-by: Håkon Bugge <[email protected]>
> >
> 
> I've been running stress testing with this for a while as part of my
> proxy-exec v31 submission, and I've not run into any issues so far.
> 
> This version definitely avoids my concern with the earlier one, so
> thanks for the update.
> 
> One tiny nit below, but I wouldn't be upset if this went in unchanged.
> 
> Acked-by: John Stultz <[email protected]>

Thanks for the a-b. Yes, my idea of a recursive solution, which became a tail recursion, could then be translated into this simple loop. I agree, much cleaner!

As to the "ok:" label, I chose that name because we did not have deadlock. But of course, it could be other errors, so will fix in v3.

I found another error here, that when running with N + 1 threads (where N is number of CPUs online) and N is 256 or 512, the N+1'th thread never executes. Related to the default unbound-workqueue active budget. I have a fix, but will send that separate from this series.


Thxs, Håkon