From: James Houghton <jthoughton@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
liam@infradead.org, Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Yang Shi <shy828301@gmail.com>,
zokeefe@google.com, hughd@google.com,
Kiryl Shutsemau <kas@kernel.org>,
jthoughton@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH] mm/khugepaged: Don't collapse uffd-minor-registered VMAs
Date: Fri, 28 Aug 2026 00:50:04 +0000 [thread overview]
Message-ID: <20260828005004.2870750-1-jthoughton@google.com> (raw)
Userfaultfd minor faults provides userspace with the ability to manually
install PTEs with UFFDIO_CONTINUE. Right now, khugepaged collapse can
map holes in the VMA when a naturally-aligned THP is present without
explicit action from userspace.
This is a problem, as it bypasses userfaultfd minor faults that
userspace is expecting to handle.
If userspace implements post-copy live migration using userfaultfd minor
faults, this situation is currently possible:
1. The VMA for guest memory is userfaultfd-minor-registered and nothing
is mapped in the page tables.
2. A stale copy of a page is present in a naturally-aligned THP (from
pre-copy live migration).
3. khugepaged collapses the mapping of the THP, installs a PMD.
4. The VM now has access to the stale contents => VM is broken.
5. After installing the correct contents, userspace attempts to map the
page with UFFDIO_CONTINUE; it gets EEXIST, indicating that something
unexpectedly mapped the page.
The naturally-aligned THP case is the only case where this is a problem.
khugepaged otherwise requires all PTEs to be present for
userfaultfd-registered VMAs (i.e., max none PTEs is 0), which is
correct. This check is essentially bypassed for naturally-aligned THPs.
To deal with this issue, completely disallow collapsing in
userfaultfd-minor-registered VMAs. This is slightly pessimistic; it
would be nice to allow MADV_COLLAPSE to work if all PTEs are in fact
present, but that seems more complex than it is worth.
Fixes: 58ac9a8993a1 ("mm/khugepaged: attempt to map file/shmem-backed pte-mapped THPs by pmds")
Cc: <stable@vger.kernel.org> # 6.1
Signed-off-by: James Houghton <jthoughton@google.com>
---
This was caught with manual review while diagnosing a related issue
that came up with in Google's live migration testing.
I've uploaded a mostly-AI-generated reproducer here[1]. As long as
/sys/kernel/mm/transparent_hugepage/shmem_enabled is not set to 'deny',
the repro should work.
[1] https://gist.github.com/48ca/d399bf534158e80241fb4937ef1ff664
---
mm/khugepaged.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index b237f6e7662a..66f956d3dd67 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -2804,6 +2804,15 @@ static enum scan_result collapse_single_pmd(unsigned long addr,
goto end;
}
+ /*
+ * Userfaultfd-minor-registered VMAs should not be collapsed, as
+ * userspace is expecting to explicitly install PTEs.
+ */
+ if (userfaultfd_minor(vma)) {
+ result = SCAN_PTE_UFFD;
+ goto end;
+ }
+
file = get_file(vma->vm_file);
pgoff = linear_page_index(vma, addr);
base-commit: 26260251022fbc2f248a3d747a9b2b961b18d2d8
--
2.55.0.897.gb25b4bd76c-goog
next reply other threads:[~2026-08-28 0:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 0:50 James Houghton [this message]
2026-08-28 9:47 ` [PATCH] mm/khugepaged: Don't collapse uffd-minor-registered VMAs Lance Yang
2026-08-28 13:07 ` Kiryl Shutsemau
2026-08-29 4:15 ` Lance Yang
2026-08-29 6:03 ` Lance Yang
2026-08-28 19:07 ` James Houghton
2026-08-29 5:26 ` Lance Yang
2026-08-31 16:51 ` James Houghton
2026-09-02 10:27 ` Kiryl Shutsemau
2026-09-02 20:41 ` James Houghton
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=20260828005004.2870750-1-jthoughton@google.com \
--to=jthoughton@google.com \
--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=hughd@google.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=shy828301@gmail.com \
--cc=stable@vger.kernel.org \
--cc=usama.arif@linux.dev \
--cc=ziy@nvidia.com \
--cc=zokeefe@google.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.