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

[Lorenzo Stoakes (ARM)]

On Fri, Sep 11, 2026 at 11:48:33PM -0400, Gregory Price wrote:
> mmap a VM_MIXEDMAP region whose ->huge_fault installs a PMD through

Gosh, shock, horror! VMA_MIXEDMAP_BIT sir! :P

(It's fine it's fine)

> 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

I definitely suggest checking out the small series [0] I sent which changes
how these kinds of semantics are expressed where I... ugh what I missed
can_madv_lru_vma()! Damn it.

Noted as a follow up :)

[0]:https://lore.kernel.org/linux-mm/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5361@xxxxxxxxxx/

>
> Even with a valid pfn the path is wrong.  The mapping carries no rmap, so

Isn't a non-rmappable page not a folio?

I mean the fact that vm_normal_folio_pmd() returns NULL is kinda saying
that :)

> 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>

LGTM in general so:

Reviewed-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>

> ---
>  mm/madvise.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/mm/madvise.c b/mm/madvise.c
> index f75a9d139980..fbb72ab49aa6 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -395,16 +395,15 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  			return 0;
>

Oh God! This function again!

>  		orig_pmd = *pmd;
> -		if (is_huge_zero_pmd(orig_pmd))
> -			goto huge_unlock;
> -
>  		if (unlikely(!pmd_present(orig_pmd))) {
>  			VM_WARN_ON_ONCE(!pmd_is_migration_entry(orig_pmd) &&
>  					!pmd_is_device_private_entry(orig_pmd));
>  			goto huge_unlock;
>  		}
>
> -		folio = pmd_folio(orig_pmd);

Again I'm wondering if pmd_folio() is just a code smell in general?

> +		folio = vm_normal_folio_pmd(vma, addr, orig_pmd);
> +		if (!folio)
> +			goto huge_unlock;
>
>  		if (folio_is_zone_device(folio))
>  			goto huge_unlock;
> --
> 2.55.0
>

--
Cheers, Lorenzo