Re: [PATCH v4] khugepaged: fix readahead lock inversion in collapse_file()

[David Hildenbrand (Arm)]

On 10/26/26 16:20, 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.

Makes sense. So we simply try readahead on all folios.

Any reason we don't simply add a second loop after the first loop where we don't
take the folio locks and do the swapin/readahead dance, then a second loop where
we do all the other stuff?

Then we don't need this fallback logic.

-- 
Cheers,

David