All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	Mani Tofigh <mt4022@columbia.edu>
Cc: Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	Nhat Pham <nphamcs@gmail.com>, Baoquan He <baoquan.he@linux.dev>,
	Barry Song <baohua@kernel.org>,
	Youngjun Park <youngjun.park@lge.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	tz2294@columbia.edu, stable@vger.kernel.org
Subject: Re: [PATCH] mm/swapfile: drop a large unmapped swap-in folio in unuse_pte()
Date: Sat, 31 Oct 2026 10:34:47 +0100	[thread overview]
Message-ID: <04155e81-a88f-4bba-a77f-0aad1ffdcde0@kernel.org> (raw)
In-Reply-To: <20261030155419.b10056c8fb37bc784b0d2778@linux-foundation.org>

On 10/30/26 23:54, Andrew Morton wrote:
> On Fri, 30 Oct 2026 15:11:56 -0400 Mani Tofigh <mt4022@columbia.edu> wrote:
> 
>> Since commit f1879e8a0c60 ("mm, swap: never bypass the swap cache even
>> for SWP_SYNCHRONOUS_IO"), a fault can read a swapped-out mTHP range into
>> one large folio in the swap cache.  The folio only becomes anon once
>> do_swap_page() maps all of it, so if the faulting PTE changes in the
>> meantime the folio stays in the swap cache while not being mapped or
>> anon:
>>
>>   Task A (fault)                       Task B
>>   do_swap_page()
>>     /* swaps in large folio F */
>>                                        madvise(MADV_DONTNEED)
>>                                          /* zaps the faulting PTE */
>>     /* PTE changed (F not mapped) */
>>
>> swapoff then maps it, which marks all of its pages as mapped and
>> exclusive, and the next fault on one of the other PTEs crashes in
>> do_swap_page():
>>
>>   [    6.424485] kernel BUG at mm/memory.c:5195!
>>
>> ...
>>
>> do_swap_page() already drops such a folio from the swap cache when it
>> can't map all of it.  Do the same in unuse_pte() so that swapoff swaps
>> the entries in again.  With the fix, nothing is reported.
>>
>> This bug was identified and confirmed with the help of a deterministic
>> hypervisor currently under development.  The C reproducer below however
>> hits it within a second.
>>
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -2518,6 +2518,18 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd,
>>  	if (!folio_matches_swap_entry(folio, entry))
>>  		return 0;
>>  
>> +	/*
>> +	 * A large folio that is not anon yet was swapped in by a page fault
>> +	 * that did not map it (yet). It can only be mapped as a whole, by
>> +	 * do_swap_page(). Drop it from the swap cache and swap in small
>> +	 * folios instead.
>> +	 */
>> +	if (unlikely(folio_test_large(folio) && !folio_test_anon(folio))) {
>> +		if (!WARN_ON_ONCE(folio_test_dirty(folio)))
>> +			swap_cache_del_folio(folio);
>> +		return 0;
>> +	}
> 
> Let's not WARN here.  If it hits and someone reports it, what do we
> tell them?  "uh, that's working as designed, no action needed".

I thought harder about this, and it just shouldn't happen.

Something that was swapped in and never mapped (!anon) that would be dirty would
reveal a bug elsewhere.

I think we can just turn that into a VM_WARN_ON_ONCE() and still drop the folio.

(there is a reason we never saw this so far in do_swap_page())

-- 
Cheers,

David


  parent reply	other threads:[~2026-10-31  9:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 19:11 [PATCH] mm/swapfile: drop a large unmapped swap-in folio in unuse_pte() Mani Tofigh via B4 Relay
2026-10-30 19:11 ` Mani Tofigh
2026-10-30 22:15 ` David Hildenbrand (Arm)
2026-10-30 22:54 ` Andrew Morton
2026-10-31  5:54   ` Kairui Song
2026-10-31  9:34   ` David Hildenbrand (Arm) [this message]
2026-10-31  5:54 ` Kairui Song

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=04155e81-a88f-4bba-a77f-0aad1ffdcde0@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baoquan.he@linux.dev \
    --cc=chrisl@kernel.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mt4022@columbia.edu \
    --cc=nphamcs@gmail.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=stable@vger.kernel.org \
    --cc=tz2294@columbia.edu \
    --cc=youngjun.park@lge.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.