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

[John Stultz <jstultz@google.com>]

On Mon, Jun 22, 2026 at 6:48 AM Haakon Bugge <haakon.bugge@oracle.com> wrote:
> > On 18 Jun 2026, at 20:55, John Stultz <jstultz@google.com> wrote:
> On Wed, Jun 17, 2026 at 5:13 AM Håkon Bugge <haakon.bugge@oracle.com> 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 even though the deadlock would have
> >> been resolved shortly thereafter. Retry a limited number of times
> >> after timeout before reporting failure.
> >>
> >> 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 <haakon.bugge@oracle.com>
> >> ---
> >> kernel/locking/test-ww_mutex.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c
> >> index 6b29a7a8f5fba..95de03179eac0 100644
> >> --- a/kernel/locking/test-ww_mutex.c
> >> +++ b/kernel/locking/test-ww_mutex.c
> >> @@ -444,6 +444,7 @@ static void stress_inorder_work(struct work_struct *work)
> >>        struct ww_acquire_ctx ctx;
> >>        int *order;
> >>        int err;
> >> +       int attempts_after_tmout = 10000;
> >>
> >>        stress->result = -ENOMEM;
> >>
> >> @@ -476,7 +477,7 @@ static void stress_inorder_work(struct work_struct *work)
> >>                        ww_mutex_unlock(&locks[order[n]]);
> >>
> >>                if (err == -EDEADLK) {
> >> -                       if (!time_after(jiffies, stress->timeout)) {
> >> +                       if ((!time_after(jiffies, stress->timeout)) || attempts_after_tmout--) {
> >>                                ww_mutex_lock_slow(&locks[order[contended]], &ctx);
> >>                                goto retry;
> >>                        }
> >
> > Thanks for sending this out! I definitely have seen timeouts hit in my
> > previous testing. Though, the approach here of "trying harder after
> > the timeout" at first glance strikes me as like a procrastinator's
> > panic. :)
>
> Hehe, I think the undersigned is a good example of a procrastinator ;-)
>
> > It might be nice to have a bit more context in the commit message as
> > to the soundness of this approach.
>
> I wrote something about it the cover letter:
>
> <quote>
> It is worth mentioning that the last patch retries up to 10,000 lock
> acquisitions 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.
> </quote>
>
> Shall I add that to the commit message?

That would be great.

> > If the deadlock resolution takes
> > longer then we expect in time,
>
> That is not the case. When we terminate due to timeout, we have no
> resolution of the deadlock. I view it as there is a probability we run
> into deadlock, let's say 10%, for each iteration. Now, if we terminate
> due to timeout - and - we are unlucky and the last iteration
> deadlocked, we cannot just return -EDEADLK, as that will mark the test
> as failed. Instead, we retry some more iterations in order to resolve
> the deadlock.

But with the retry count needing to be set to 10,000 it seems like
more then just being unlucky on the last iteration, no?

I'm still a bit wary on this change, but I am very eager to see these
occasional failures be sorted out, so thank you for your efforts here!

thanks
-john