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