Re: [PATCH v2] khugepaged: hold invalidate_lock across collapse_file() readahead

[Lance Yang <lance.yang@linux.dev>]

On 2026/10/15 20:26, David Hildenbrand (Arm) wrote:
> On 9/13/26 20:48, Lorenzo Stoakes (ARM) wrote:
>> (Nguyen - do not send v2 in reply to v1, look across mm and see how things are
>> done here).
>>
>> somebody who has a
>>
>> On Sun, Sep 13, 2026 at 11:17:00AM -0700, Andrew Morton wrote:
>>> On Sun, 13 Sep 2026 23:36:44 +0700 Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com> wrote:
>>>
>>>> collapse_file() calls page_cache_sync_readahead() to fault in missing
>>>> pages before collapsing them into a THP. That helper takes
>>>> mapping->invalidate_lock itself for the duration of the call, then
>>>> drops it -- but truncate (e.g. ext4_setattr() -> truncate_pagecache())
>>>> takes invalidate_lock and then waits on each page's folio lock while
>>>> holding it. If collapse_file() has already locked one of those folios
>>>> by the time truncate reaches it, and then tries to acquire
>>>> invalidate_lock again (e.g. on the first readahead call, since
>>>> invalidate_lock is not yet held at that point), the two paths can
>>>> deadlock/hang on each other's lock: truncate blocked on the folio lock
>>>> collapse holds, and collapse blocked waiting for invalidate_lock that
>>>> truncate holds.
>>>>
>>>> Reproducing this over ~150,000 collapse iterations with truncate
>>>> racing concurrently reliably hits hung_task: blocked tasks within
>>>> about 20 seconds on an unpatched kernel.
>>>>
>>>> Fix it by taking invalidate_lock_shared once for the whole scan, after
>>>> alloc_charge_folio() succeeds and before locking any folio, and using
>>>> page_cache_ra_unbounded() directly in the readahead call site instead
>>>> of page_cache_sync_readahead(), since the latter would try to retake
>>>> the lock we already hold. page_cache_ra_unbounded() does not clamp to
>>>> EOF like the helper it replaces, so clamp the requested range
>>>> explicitly.
>>>>
>>>> 730633f0b7f9 added invalidate_lock acquisition around readahead but
>>>> missed collapse_file(), which already locks pages while calling
>>>> readahead; later filesystem conversions made the deadlock reachable by
>>>> taking invalidate_lock before waiting on page locks during truncate.
>>>>
>>>> Reported-by: syzbot+16bf7cd0ebeb1de93aa5@syzkaller.appspotmail.com
>>>> Closes: https://syzkaller.appspot.com/bug?extid=16bf7cd0ebeb1de93aa5
>>>> Fixes: 730633f0b7f9 ("mm: Protect operations adding pages to page cache with invalidate_lock")
>>>
>>> (You forgot to cc the original author)
>>
>> Also a change log, and that mm doesn't like sending a respin in-reply-to a
>> previous version. Which is all consistent with somebody using e.g. openclaw to
>> pepper generated patches across the kernel...
>>
>>>
>>> Five years.
>>>
>>> I wonder why this hasn't been discovered by lockdep, AI, syzbot or any
>>> other of the tools we've been using for so long.
>>>
>>> Thanks for doing all this.
>>
>> See https://lore.kernel.org/linux-mm/aqbtfms0_2ULBIT7@gremlin/
>>
>> I am not really entirely happy with somebody who has sent a flurry of patches
>> across disparate subsystems with no previous track record being in charge of a
>> potentially backported fix.
>>
>> It's David's decision but I think this fix should be taken over by somebody
>> else.
> 
> So what's the status of this? Any volunteers? Otherwise I'll polish this up.

I can take this over if no one else volunteers :D