All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: pfalcato@suse.de
Cc: akpm@linux-foundation.org, david@kernel.org, ziy@nvidia.com,
	baolin.wang@linux.alibaba.com, liam@infradead.org,
	nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com,
	baohua@kernel.org, usama.arif@linux.dev, kas@kernel.org,
	jack@suse.cz, djwong@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, hch@lst.de,
	ngocthang2710.1999@gmail.com,
	syzbot+16bf7cd0ebeb1de93aa5@syzkaller.appspotmail.com,
	stable@vger.kernel.org
Subject: Re: [PATCH v4] khugepaged: fix readahead lock inversion in collapse_file()
Date: Tue, 27 Oct 2026 10:55:07 +0800	[thread overview]
Message-ID: <20261027025507.59451-1-lance.yang@linux.dev> (raw)
In-Reply-To: <at9_1mf2kLqMX8-W@pedro-suse.tail5790ac.ts.net>


On Mon, Oct 26, 2026 at 04:33:08PM +0000, Pedro Falcato wrote:
>On Mon, Oct 26, 2026 at 11:20:13PM +0800, 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>
>
>Thanks for the patch! This looks almost perfect!

Thanks Pedro!

>
>> ---
>> v3 -> v4:
>>  - Move readahead after rollback and retry collapse once (per Pedro).
>>  - Drop the preparation pass and its redundant uptodate check (per
>>    Baolin and Pedro). Thanks!
>>  - https://lore.kernel.org/all/20261016065920.4153-1-lance.yang@linux.dev/
>> 
>>  mm/khugepaged.c | 44 +++++++++++++++++++++++++++++++++-----------
>>  1 file changed, 33 insertions(+), 11 deletions(-)
>> 
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index da91762f6358..0d3bd9e23613 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -2239,6 +2239,8 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
>>  	enum scan_result result = SCAN_SUCCEED;
>>  	int nr_none = 0;
>>  	bool is_shmem = shmem_file(file);
>> +	bool do_readahead = false;
>> +	bool readahead_done = false;
>>  
>>  	/*
>>  	 * MADV_COLLAPSE ignores shmem huge config, so do not check shmem
>> @@ -2256,6 +2258,10 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
>>  
>>  	mapping_set_update(&xas, mapping);
>>  
>> +retry:
>> +	result = SCAN_SUCCEED;
>> +	do_readahead = false;
>> +	xas_set_order(&xas, start, HPAGE_PMD_ORDER);
>>  	__folio_set_locked(new_folio);
>>  	if (is_shmem)
>>  		__folio_set_swapbacked(new_folio);
>> @@ -2320,17 +2326,9 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
>>  			}
>>  		} else {	/* !is_shmem */
>>  			if (!folio || xa_is_value(folio)) {
>> -				xas_unlock_irq(&xas);
>> -				page_cache_sync_readahead(mapping, &file->f_ra,
>> -							  file, index,
>> -							  end - index);
>> -				/* drain lru cache to help folio_isolate_lru() */
>> -				lru_add_drain();
>> -				folio = filemap_lock_folio(mapping, index);
>> -				if (IS_ERR(folio)) {
>> -					result = SCAN_FAIL;
>> -					goto xa_unlocked;
>> -				}
>> +				do_readahead = !readahead_done;
>> +				result = SCAN_FAIL;
>> +				goto xa_locked;
>>  			} else if (folio_test_dirty(folio)) {
>>  				/*
>>  				 * This page is dirty because it hasn't
>> @@ -2657,6 +2655,30 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
>>  	new_folio->mapping = NULL;
>>  
>>  	folio_unlock(new_folio);
>> +
>> +	/* Readahead may take invalidate_lock; source folios are unlocked. */
>> +	if (do_readahead) {
>> +		for (index = start; index < end;) {
>> +			folio = filemap_lock_folio(mapping, index);
>
>I'm not sure if there's a point in locking the folio. If we are retrying,
>then the logic above will lock it anyway and check uptodate. So I don't
>think there's much of a point doing it here. Right?
>
>So I think we could get away with a filemap_get_folio() here, and no
>filemap_lock_folio() after RA. Unless you're intent on waiting for RA
>right before failing, but I don't see a point in that.

Right, waiting for RA is what I intended here. Without that wait, the
retry can hit folio_trylock() while the read is still in flight and bail
out with SCAN_PAGE_LOCK, before it even gets to the uptodate check.

If the read completes successfully, we can continue with collapse.
That's why I kept the wait before retrying. Do you think waiting isn't
worth it here, and we'd be better off leaving collapse to a later
attempt?

>
>With that addressed:
>
>Reviewed-by: Pedro Falcato <pfalcato@suse.de>

Really appreciated!

>> +			if (IS_ERR(folio)) {
>> +				page_cache_sync_readahead(mapping, &file->f_ra,
>> +							  file, index, end - index);
>> +				folio = filemap_lock_folio(mapping, index);
>> +				if (IS_ERR(folio)) {
>> +					result = SCAN_FAIL;
>> +					goto out_put;
>> +				}
>> +			}
>> +			index = folio_next_index(folio);
>> +			folio_unlock(folio);
>> +			folio_put(folio);
>> +		}
>> +		/* Drain the local LRU batch before retrying isolation. */
>> +		lru_add_drain();
>> +		readahead_done = true;
>> +		goto retry;
>> +	}
>> +out_put:
>>  	folio_put(new_folio);
>>  out:
>>  	VM_BUG_ON(!list_empty(&pagelist));
>> -- 
>> 2.49.0
>> 
>
>-- 
>Pedro
>


  reply	other threads:[~2026-10-27  2:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26 15:20 [PATCH v4] khugepaged: fix readahead lock inversion in collapse_file() Lance Yang
2026-10-26 16:33 ` Pedro Falcato
2026-10-27  2:55   ` Lance Yang [this message]
2026-10-27 10:30     ` Pedro Falcato
2026-10-27 11:06 ` David Hildenbrand (Arm)
2026-10-27 13:05   ` Pedro Falcato
2026-10-27 13:58     ` David Hildenbrand (Arm)
2026-10-27 16:27       ` Lance Yang
2026-10-27 19:03 ` David Hildenbrand (Arm)
2026-10-27 19:44 ` Zi Yan
2026-10-29  6:04 ` Baolin Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261027025507.59451-1-lance.yang@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=kas@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ngocthang2710.1999@gmail.com \
    --cc=nico.pache@linux.dev \
    --cc=pfalcato@suse.de \
    --cc=ryan.roberts@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+16bf7cd0ebeb1de93aa5@syzkaller.appspotmail.com \
    --cc=usama.arif@linux.dev \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.