Re: [PATCH v2 4/4] test-ww_mutex: Retry lock acquisition after timeout if deadlocked

> On 29 Jul 2026, at 02:07, John Stultz <[email protected]> wrote:
> 
> On Mon, Jul 13, 2026 at 9:37 AM Håkon Bugge <[email protected]> wrote:
> >
> > stress_inorder_work() terminates when its timeout expires. If the
> > final lock acquisition attempt returns -EDEADLK at that point, the
> > test may report a false failure.
> >
> > With a high number of threads and few locks, there is a very high
> > probability that a thread will be subject to lock contention. That
> > implies, when the loop times out, we will most probably have been
> > exposed to a -EDEADLK return.
> >
> > Therefore, we retry a finite number of times after timeout before
> > reporting failure.
> >
> > We retry up to 10,000 loops after timeout. This value was determined
> > empirically: 10 and 100 retries were insufficient on the test systems,
> > while 10,000 provided stable results and avoided false negatives.
> >
> > Without this commit, we may see in the log:
> >
> > Beginning ww (wound) mutex selftests
> > stress (stress_inorder_work) failed with -35
> >
> > Fixes: cfa92b6d5207 ("locking/ww_mutex/test: Make sure we bail out instead of livelock")
> > Signed-off-by: Håkon Bugge <[email protected]>
> 
> So I've utilized this in my testing with proxy-exec v31 and have not
> seen any practical troubles with it.
> 
> However, I still am not very happy with the post-timeout retrys,
> particularly as it is such a high retry value.
> 
> It still feels like we're papering over a problem we don't understand
> well, and it might be better to leave it failing until we can better
> articulate what's going on and why this is the right solution.
> 
> The rest of the patchset looks great, but I'd maybe drop this one from
> the series for now.

I agree. This is not a real fix. On a larger 512 CPU BM system, it still fails. I would suggest to disable this test for now, so that the other stable tests can be regularly executed to avoid regressions.


Thxs, Håkon