Re: Regression on linux-next (next-20260324 )
From: John Stultz
Date: Tue Apr 21 2026 - 02:48:20 EST
On Mon, Apr 20, 2026 at 6:03 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Mon, Mar 30, 2026 at 09:50:37PM +0200, Peter Zijlstra wrote:
> > On Mon, Mar 30, 2026 at 01:56:33PM +0530, Borah, Chaitanya Kumar wrote:
> > > > diff --git a/kernel/locking/ww_mutex.h b/kernel/locking/ww_mutex.h
> > > > index b1834ab7e782..bb8b410779d4 100644
> > > > --- a/kernel/locking/ww_mutex.h
> > > > +++ b/kernel/locking/ww_mutex.h
> > > > @@ -42,7 +42,7 @@ __ww_waiter_last(struct mutex *lock)
> > > > struct mutex_waiter *w = lock->first_waiter;
> > > > if (w)
> > > > - w = list_prev_entry(w, list);
> > > > + w = __ww_waiter_prev(lock, w);
> > > > return w;
> > > > }
> > > Thank you for the response, Peter. Unfortunately, the issue is still seen
> > > with this change.
> >
> > Bah, indeed. Looking at this after the weekend I see that it's actually
> > wrong.
> >
> > But I haven't yet had a new idea. I don't suppose there is a relatively
> > easy way to reproduce this issue outside of your CI robot?
> >
> > My current working thesis is that since this is graphics, this is
> > ww_mutex related. I'll go over this code once more...
So I tripped over this in my own testing today preping proxy patches,
bisecting it down to the same problematic commit 25500ba7e77c
("locking/mutex: Remove the list_head from struct mutex").
Inteed it does seem related to ww_mutexes, as I can pretty easily
reproduce it with defconfig + CONFIG_WW_MUTEX_SELFTEST=y using
qemu-system-x86
Where the test will basically hang on bootup.
> Since you've not provided a reproducer, can I ask you to try the below?
>
Unfortunately that patch doesn't seem to sort it (see the same
behavior). I'm about cooked for tonight so I'll have to look more
closely tomorrow.
thanks
-john