Re: [PATCH v2 2/2] mm/madvise: use vm_normal_folio_pmd() in cold/pageout PMD range

From: Zi Yan

Date: Sat Sep 12 2026 - 14:03:30 EST


On Fri Sep 11, 2026 at 11:48 PM EDT, Gregory Price wrote:
> mmap a VM_MIXEDMAP region whose ->huge_fault installs a PMD through
> vmf_insert_pfn_pmd() - mshv_vtl_low does this, and needs CAP_SYS_ADMIN
> to open - then:
>
> madvise(p, PMD_SIZE, MADV_PAGEOUT);
>
> With a stand-in module for the driver:
>
> BUG: unable to handle page fault for address: fffff587c0000008
> RIP: 0010:madvise_cold_or_pageout_pte_range+0x410/0x9b0
> walk_pgd_range+0x52b/0xaf0
> __walk_page_range+0x6a/0x1d0
> walk_page_range_vma_unsafe+0x8e/0x120
> madvise_pageout+0xb2/0x180
> madvise_vma_behavior+0x46b/0xa90
> do_madvise+0x108/0x190
> __x64_sys_madvise+0x26/0x30
>
> Nothing validates the pfn on the way in:
>
> can_madv_lru_vma() rejects VM_PFNMAP, but not VM_MIXEDMAP
> can_fault() *pfn = vmf->pgoff & ~(mask >> PAGE_SHIFT);
> vmf_insert_pfn_pmd() no pfn_valid() check
> pmd_folio() pfn_to_page() -> unpopulated vmemmap
>
> Even with a valid pfn the path is wrong. The mapping carries no rmap, so
> folio_maybe_mapped_shared() sees mapcount 0, and the walker goes on to
> folio_deactivate(), or folio_isolate_lru() plus reclaim_pages(), against a
> folio this mapping does not own.
>
> Use vm_normal_folio_pmd() and skip on NULL, as the PTE half of this same
> walker already does with vm_normal_folio(). This also filters the huge
> zero PMD, so its separate check is no longer needed.
>
> Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject")
> Reported-by: sashiko-bot <sashiko-bot@xxxxxxxxxx>
> Closes: https://sashiko.dev/#/patchset/20260817220810.1175596-1-gourry%40gourry.net
> Cc: stable@xxxxxxxxxxxxxxx # v6.19+
> Assisted-by: LLM
> Signed-off-by: Gregory Price (Meta) <gourry@xxxxxxxxxx>
> ---
> mm/madvise.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
LGTM.

Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>

--
Best Regards,
Yan, Zi