[PATCH 07/46] mm/filemap: don't lose a folio lock wakeup to a signal

[Rik van Riel]

On Tue, 2026-10-27 at 16:10 +0000, Pedro Falcato wrote:
> On Tue, Oct 27, 2026 at 12:17:27AM +0100, David Hildenbrand (Arm)
> wrote:
> > From: Josef Bacik <josef at toxicpanda.com>
> > 
> > An exclusive waiter in folio_wait_bit_common() can leave the wait
> > loop
> > because of a fatal signal, then be woken by folio_unlock() before
> > finish_wait(). If the waker did not hand over the lock, the waiter
> > returns
> > -EINTR without trying to acquire it.
> > 
> > folio_wake_bit() stops after waking the first exclusive waiter, so
> > this
> > loses the wakeup and can leave other waiters asleep indefinitely on
> > an
> > unlocked folio.
> > 
> > After finish_wait(), let a waiter woken without a lock handoff try
> > once
> > more to acquire the lock. If successful, return success so the
> > caller's
> > eventual unlock wakes the next waiter. Otherwise, the current lock
> > owner
> > will do so.
> 
> Has this been reproduced? I feel like this would've been found out by
> now?
> 
I have seen stuck waiters, on a fleet of millions
of systems, but I have never tracked one down when
the root cause was transitory, and no longer
visible after things got stuck.

There's no way to tell whether or not this was
the root cause, though the symptoms match.


-- 
All Rights Reversed.