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

David Hildenbrand (Arm) david at kernel.org
Tue Oct 27 12:18:18 PDT 2026


On 10/27/26 17:10, 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?

Let me dig ... I don't find mention in the notes, but I was told that most of
these things have reproducers.

I guess it's harder to hit in practice, because you need a fatal signal and then
keep the other waiter alive while nobody else will take that lock in a timely
fashion.

I asked codex to try writing one but it refuses for security reasons :)

-- 
Cheers,

David



More information about the kexec mailing list