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

[Pedro Falcato <pfalcato@suse.de>]

On Tue, Oct 27, 2026 at 12:06:05PM +0100, David Hildenbrand (Arm) wrote:
> 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?

I'm not sure I understand. You want to nest two loops? Or do you want a loop
upfront? I don't think we want a loop upfont. That's slow and involves
starting/waiting for IO. Fallback logic makes more sense IMO.

FWIW, I plan on rebasing my refactoring patches for 7.5, and hopefully knock
some sense into this code. That will hopefully make this cleaner.

-- 
Pedro