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.

Fair.  pte_folio() does not fit the abstraction as it stands, so I will
drop it.

I thought that maybe we can rework vm_normal_*() to be a predicate on a
page table entry, so if it returns true the caller can safely use
pxx_folio(). It would be a cleaner interface in my opinion.

vm_ops->find_normal_page() breaks the idea, though.  Xen (being the single
user of the vm_op) wants the special bit to indicate a custom translation
to the page here.  A bool cannot describe this.

Ugh..

-- 
  Kiryl Shutsemau / Kirill A. Shutemov