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

"David Hildenbrand (Arm)" <[email protected]>
Newsgroups org.kernel.vger.linux-trace-kernel,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kvack.linux-mm
Message-ID <[email protected]>
On 8/17/26 00:45, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <[email protected]>
> 
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.