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

On Tue, Aug 18, 2026 at 07:09:48PM +0200, David Hildenbrand (Arm) wrote:

On 8/17/26 00:45, Kiryl Shutsemau wrote:

quoted

From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>

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.

[...]

quoted

+/**
+ * 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.

I'm also a bit concerned about softleaves here. Kinda implying every pte
has a folio is problematic in general especially if there is nothing
guarding against that being used incorrectly.

pte_page() is more of an low-level arch-helper it seems to me (let's go
look up a PFN from the vmemmap modulo arch stuff around the pte).

So yeah I'm a little iffy about it too! :)

--
Cheers,

David

--
Cheers, Lorenzo