mirror of https://lore.kernel.org/lkml/
 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: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 19:11 Mani Tofigh via B4 Relay
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®