Re: Regression on linux-next (next-20260324 )

K Prateek Nayak
2026-04-22T12:38:47Z

On 4/21/2026 3:45 PM, Peter Zijlstra wrote:
> On Mon, Apr 20, 2026 at 11:45:12PM -0700, John Stultz wrote:
>
>> 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.
>
> *groan* indeed. This of course means no CI is running this thing :-(
>
> Anyway, yay for deterministic reproducer. Let me go prod at this.

So I managed to unblock the ww-mutext_test with:

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 186b463fe326..623c892c3742 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -209,8 +209,13 @@ __mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
hung_task_set_blocker(lock, BLOCKER_TYPE_MUTEX);
debug_mutex_add_waiter(lock, waiter, current);

- if (!first)
+ if (!first) {
first = lock->first_waiter;
+ } else if (first == lock->first_waiter) {
+ list_add_tail(&waiter->list, &first->list);
+ lock->first_waiter = waiter;
+ return;
+ }

if (first) {
list_add_tail(&waiter->list, &first->list);
diff --git a/kernel/locking/ww_mutex.h b/kernel/locking/ww_mutex.h
index 016f0db892a5..2fcd6221fc64 100644
--- a/kernel/locking/ww_mutex.h
+++ b/kernel/locking/ww_mutex.h
@@ -28,10 +28,9 @@ static inline struct mutex_waiter *
__ww_waiter_prev(struct mutex *lock, struct mutex_waiter *w)
__must_hold(&lock->wait_lock)
{
- w = list_prev_entry(w, list);
if (lock->first_waiter == w)
return NULL;
-
+ w = list_prev_entry(w, list);
return w;
}

---

First hunk orders the first_waiter if we are attaching to the
tail of current first_waiter which would have previously ended
up next to list_head.

The second hunk deals with __ww_waiter_prev() - since we are
traversing back from w, I guess we must first check if we are
at the first_waiter already or not.

I'll let you stare and see if it is correct or not.

--
Thanks and Regards,
Prateek