Re: [RFC PATCH 01/57] mm: add pte_folio()

[David Hildenbrand (Arm)]

On 8/17/26 00:45, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> 
> Callers that want the folio behind a present PTE spell it out as
> page_folio(pte_page(pte)).
> 
> Add pte_folio() as the folio companion to pte_page(), and convert the
> callers in fs/proc/task_mmu.c and mm/hugetlb.c.
> 
> Preparation for the anonymous collapse engine, which reads the folio
> behind a PTE in several places.

[...]

>  
> +/**
> + * pte_folio - Return the folio mapped by a present PTE.
> + * @pte: A present page table entry.
> + *
> + * The folio companion to pte_page(); only meaningful for a present PTE
> + * that maps a struct-page-backed folio.
> + *
> + * Return: The folio containing the page @pte maps.
> + */
> +static inline struct folio *pte_folio(pte_t pte)
> +{
> +	return page_folio(pte_page(pte));
> +}

There is a reason why most code doesn't need that: because they should be using
vm_normal_page() / vm_normal_folio(), or need the exact page and handle special
ptes differently (see gup.c that uses pte_page()).

And other code that uses pte_page() doesn't really operate on folios AFAIKs.

That's also why you are only touching hugetlb code here.

IOW, there must be a pretty good reason for us to add a non-hugetlb helper when
that looks like a good fit for common code when it's really only hugetlb that
does weird things (and doesn't need the exact page!).

If we really *need* this helper, we should spell out clearly that it is very
likely the wrong thing to use outside hugetlb code.

-- 
Cheers,

David