Re: [PATCH 6.12.y] khugepaged: fix readahead lock inversion in collapse_file()

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

On 2026/11/14 00:27, Zi Yan wrote:
> On 11 Nov 2026, at 8:26, Lance Yang wrote:
> 
>> collapse_file() can call page_cache_sync_readahead() while still holding
>> source folios locked. If truncate holds mapping->invalidate_lock
>> exclusively and waits for one of those folios, readahead waits for
>> invalidate_lock and neither side can make progress.
>>
>> We need to release those folio locks before starting readahead. On a page
>> cache miss, roll back first, populate the collapse range, and retry once.
>> Doing readahead after rollback avoids an extra pass when all folios are
>> already present. If another miss occurs on retry, give up rather than keep
>> retrying while truncate or reclaim removes folios.
>>
>> Keep page_cache_sync_readahead() and wait for read I/O with
>> filemap_lock_folio(), releasing each folio before moving to the next. The
>> existing uptodate check during collapse still handles read errors.
>>
>> Shmem uses shmem_get_folio() for swapin and fallocated folios without
>> taking mapping->invalidate_lock, so it is unaffected.
>>
>> 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")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>> Reviewed-by: Pedro Falcato <pfalcato@suse.de>
>> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
>> Acked-by: Zi Yan <ziy@nvidia.com>
>> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>> Link: https://patch.msgid.link/20261026152013.10511-1-lance.yang@linux.dev
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>>
>> (cherry picked from commit eadce52a9ef657d561b3e76c9b5f178bd99735f5)
>> ---
>> Backport to 6.12:
>> - 6.12 still takes invalidate_lock in collapse_file() after locking the
>>    source folios. Use filemap_invalidate_trylock_shared() and roll back
>>    on contention, otherwise the same deadlock is possible even after
>>    moving readahead.
>>
>>   mm/khugepaged.c | 49 +++++++++++++++++++++++++++++++++++++------------
>>   1 file changed, 37 insertions(+), 12 deletions(-)
>>
> <snip>
> 
>> @@ -2040,7 +2038,10 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
>>   		 * in do_dentry_open() truncating the page cache. This is
>>   		 * particularly important if there are dirty folios in transit.
>>   		 */
>> -		filemap_invalidate_lock_shared(mapping);
>> +		if (!filemap_invalidate_trylock_shared(mapping)) {
>> +			result = SCAN_FAIL;
>> +			goto rollback;
>> +		}
>>   		filemap_nr_thps_inc(mapping);
>>   		/*
>>   		 * Paired with the fence in do_dentry_open() -> get_write_access()
> 
> This additional change to address the same deadlock makes sense to me.
> 
> Acked-by: Zi Yan <ziy@nvidia.com>

Much appreciated, thanks!