From: Chris Down <chris@chrisdown.name>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
kernel-team@fb.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH v2 0/3] mm/huge_memory: Fix move_pages_huge_pmd() for huge zero pages
Date: Thu, 26 Feb 2026 22:15:04 +0800 [thread overview]
Message-ID: <aaBVaHs8rIkNcwM0@chrisdown.name> (raw)
Changes since v1:
- Reworked patch 2 per David's feedback to stop reconstructing the huge
zero PMD and instead preserve PMD state from src_pmdval, then apply
move_soft_dirty_pmd() and clear_uffd_wp_pmd().
- Added regression tests.
- As a side note, I've kept the two mm fixes split intentionally for
stable backports, even though patch one immediately gets superseded by
patch two. The reason is they track back to different commits, so
although patch 2 rewrites the same branch in newer trees, keeping the
fixes separate preserves the correct Fixes: annotations and lets
stable pick the applicable fix for a given tree.
---
Two fixes for the huge zero page path in move_pages_huge_pmd()
(UFFDIO_MOVE).
Patch 1 fixes a use of NULL folio introduced by the folio_mk_pmd()
conversion in commit e3981db444a0 ("mm: add folio_mk_pmd()"), which
replaced mk_huge_pmd(src_page, ...) with folio_mk_pmd(src_folio, ...) in
the huge zero page branch where src_folio is explicitly NULL. With
SPARSEMEM_VMEMMAP this silently produces a PMD with a bogus PFN, on
other memory models it is a NULL deref.
Patch 2 fixes huge zeropage refcount corruption after commit
d82d09e48219 ("mm/huge_memory: mark PMD mappings of the huge zero folio
special") by preserving the moved huge zero PMD state instead of
reconstructing the destination PMD from the folio. This keeps the PMD
special bit intact on CONFIG_ARCH_HAS_PTE_SPECIAL architectures and
avoids vm_normal_page_pmd() misclassifying the moved huge zeropage PMD
as a normal page.
Chris Down (3):
mm/huge_memory: Fix use of NULL folio in move_pages_huge_pmd()
mm/huge_memory: Prevent huge zeropage refcount corruption in PMD move
selftests/mm: Add UFFDIO_MOVE huge zeropage PMD regression test
mm/huge_memory.c | 3 +-
tools/testing/selftests/mm/uffd-unit-tests.c | 176 +++++++++++++++++++
2 files changed, 178 insertions(+), 1 deletion(-)
--
2.51.2
reply other threads:[~2026-02-26 14:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=aaBVaHs8rIkNcwM0@chrisdown.name \
--to=chris@chrisdown.name \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
--cc=willy@infradead.org \
/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