Re: [PATCH v3 13/13] mm/huge_memory: add and use has_deposited_pgtable()

["Lorenzo Stoakes (Oracle)" <ljs@kernel.org>]

On Thu, Apr 02, 2026 at 11:19:07AM +0800, Yin Tirui wrote:
>
>
> On 3/21/26 02:07, Lorenzo Stoakes (Oracle) wrote:
>
> > +static bool has_deposited_pgtable(struct vm_area_struct *vma, pmd_t pmdval,
> > +		struct folio *folio)
> > +{
> > +	/* Some architectures require unconditional depositing. */
> > +	if (arch_needs_pgtable_deposit())
> > +		return true;
> > +
> > +	/*
> > +	 * Huge zero always deposited except for DAX which handles itself, see
> > +	 * set_huge_zero_folio().
> > +	 */
> > +	if (is_huge_zero_pmd(pmdval))
> > +		return !vma_is_dax(vma);
> > +
> > +	/*
> > +	 * Otherwise, only anonymous folios are deposited, see
> > +	 * __do_huge_pmd_anonymous_page().
> > +	 */
> > +	return folio && folio_test_anon(folio);
> > +}
>
> Hi Lorenzo,
>
> I just wanted to mention a potential intersection with my upcoming v4 of
> the "mm: add huge pfnmap support for remap_pfn_range()" series [1].
>
> To safely support PMD splitting on partial unmaps, my series makes
> VM_PFNMAP huge pages allocate and deposit page tables. However, they
> neither have an underlying struct folio nor are anonymous.
>
> Given the has_deposited_pgtable() helper, do you have any suggestions on
> what would be the cleanest way to integrate the VM_PFNMAP condition into it?


I mean you would have needed to handle this case in any event, since this change
is strictly an equivalent reworking of zap_huge_pmd().

But it seems that doing so has clarified the requirements somewhat here :)

I haven't had a look at that series yet (please cc this email if you weren't
already, I do filter a lot of stuff due to how much mail I get daily)

So if this is a PMD leaf entry it will be present and PFN map, so I'd have
thought simply adding:

	/* Huge PFN map must deposit, as cannot refault. */
	if (vma_test(vma, VMA_PFNMAP_BIT))
		return true;

Would suffice?

By the way, I am wondering if the prot bits are correctly preserved on page
table deposit, as this is key for pfn map (e.g. if the range is uncached, for
instance). That's something to check and ensure is correct.

I _suspect_ they will be, as we have pretty well established mechanisms for that
(propagate vma->vm_page_prot etc.) but definitely worth making sure.

>
> [1]
> https://lore.kernel.org/linux-mm/20260228070906.1418911-5-yintirui@huawei.com/
>
> --
> Yin Tirui
>

Cheers, Lorenzo