From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,vbabka@kernel.org,stable@vger.kernel.org,sashiko-bot@kernel.org,pfalcato@suse.de,peterx@redhat.com,ljs@kernel.org,liam@infradead.org,jgg@ziepe.ca,jannh@google.com,david@kernel.org,gourry@gourry.net,akpm@linux-foundation.org
Subject: [merged mm-stable] proc-task_mmu-handle-special-pmds-in-clear_refs-and-pagemap.patch removed from -mm tree
Date: Mon, 12 Oct 2026 21:31:54 -0700 [thread overview]
Message-ID: <20261013043154.775E31F00893@smtp.kernel.org> (raw)
The quilt patch titled
Subject: proc/task_mmu: handle special PMDs in clear_refs and pagemap
has been removed from the -mm tree. Its filename was
proc-task_mmu-handle-special-pmds-in-clear_refs-and-pagemap.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Gregory Price <gourry@gourry.net>
Subject: proc/task_mmu: handle special PMDs in clear_refs and pagemap
Date: Sat, 12 Sep 2026 08:28:22 -0400
mshv_vtl_low can install a special PMD from a PFN supplied in the mmap file
offset. That PFN need not have a memmap entry. Reading /proc/PID/pagemap
or writing /proc/PID/clear_refs for such a mapping oopses the kernel.
With a test driver mapping the PFN at the 1 TiB mark:
echo 1 > /proc/self/clear_refs
BUG: unable to handle page fault for address: fffffb5b80000008
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
RIP: 0010:clear_refs_pte_range+0xb1/0x1e0
Call Trace:
walk_pgd_range+0x50a/0xad0
__walk_page_range+0x6a/0x1d0
walk_page_range_mm_unsafe+0x193/0x230
clear_refs_write+0x18e/0x3f0
pread(pagemap_fd, buf, 512 * 8, addr / PAGE_SIZE * 8)
BUG: unable to handle page fault for address: fffff57840000008
RIP: 0010:pagemap_pmd_range+0x3cf/0x6b0
Call Trace:
walk_pgd_range+0x50a/0xad0
__walk_page_range+0x6a/0x1d0
walk_page_range_mm_unsafe+0x193/0x230
pagemap_read+0x1dc/0x350
clear_refs_pte_range() passes the PMD to pmd_folio(), while
pagemap_pmd_range_thp() uses pmd_page() followed by page_folio().
Both paths assume the PFN has a struct page and dereference bad address.
Use vm_normal_folio_pmd() and vm_normal_page_pmd() so clear_refs skips
folio operations and pagemap skips folio-derived flags for special PMDs.
This matches the PTE paths, which already use vm_normal_folio() and
vm_normal_page().
User-facing notes:
- Pagemap still reports PM_PRESENT and the PFN to a CAP_SYS_ADMIN reader.
- For a special PMD backed by a valid memmap entry and for the huge
zero PMD, PM_FILE changes from set to clear.
- PM_MMAP_EXCLUSIVE is already clear in both cases.
- The output for an anonymous THP is unchanged.
Tested in QEMU with the test driver on broken and fixed kernels. Both proc
operations oops before the fix and return 0 after it.
This is technically reachable via mshv_vtl_low, so I tagged it stable.
Link: https://lore.kernel.org/20260912122822.3348978-1-gourry@gourry.net
Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject")
Signed-off-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260912034833.2952750-1-gourry%40gourry.net
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Assisted-by: LLM
Cc: Jann Horn <jannh@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: Peter Xu <peterx@redhat.com>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: <stable@vger.kernel.org> # v6.19+
---
fs/proc/task_mmu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/proc/task_mmu.c~proc-task_mmu-handle-special-pmds-in-clear_refs-and-pagemap
+++ a/fs/proc/task_mmu.c
@@ -1704,7 +1704,9 @@ static int clear_refs_pte_range(pmd_t *p
if (!pmd_present(*pmd))
goto out;
- folio = pmd_folio(*pmd);
+ folio = vm_normal_folio_pmd(vma, addr, *pmd);
+ if (!folio)
+ goto out;
/* Clear accessed and referenced bits. */
pmdp_test_and_clear_young(vma, addr, pmd);
@@ -2024,7 +2026,7 @@ static int pagemap_pmd_range_thp(pmd_t *
goto populate_pagemap;
if (pmd_present(pmd)) {
- page = pmd_page(pmd);
+ page = vm_normal_page_pmd(vma, addr, pmd);
flags |= PM_PRESENT;
if (pmd_soft_dirty(pmd))
_
Patches currently in -mm which might be from gourry@gourry.net are
mm-damon-use-damon_get_monitor_folio-for-hugetlb-entries.patch
reply other threads:[~2026-10-13 4:31 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=20261013043154.775E31F00893@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=jannh@google.com \
--cc=jgg@ziepe.ca \
--cc=liam@infradead.org \
--cc=ljs@kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=sashiko-bot@kernel.org \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.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 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.