[RFC PATCH 0/7] Implement a new generic pagewalk API

Oscar Salvador
2026-04-12T17:43:02Z

[WARNING]

This is not yet fully complete, but before investing more time into it I would like
to know whether 1) this is heading into the right direction and 2) this is something
we are still interested in.

Kudos go to David, who was the person suggesting the interface and
he gave me some ideas where to begin, besides providing feedback
on early stages (in case there is something stupid don't blame him, blame me)

Also, I would like to thank Vlastimil, who helped me running this
patchset quite a few times through Claude, to catch some fixes.

But nevertheless, it still has bugs, and lacks some functionality, but I
think it is good enough as RFC to see what people think of it.

[/WARNING]

In the LSFMM/BFP 2025, there was a general agreement that we 1) would like to have
a generic pagewalk API 2) that replaces the existing one with callbacks if possible
and 3) that HugeTLB can use without the need to special case it (e.g: not having to
depend on .hugetlb_entry callbacks)., which means having a lot of duplicated
code and also having a lot of special casing just because hugetlb lore.

pt_range_walk API tries to do that and replaces the old behaviour of "in
HugeTLB world everything reads as a PTE" and starts reading HugeTLB entries
the way they really are, that means interpreting them as PMD/PUD entries and
contiguous-PMD/PTE entries.

In order to achieve that, we need some infrastructure we did not really need until
know, in order to be able to read HugeTLB pages as PUD/PMD entries.
E.g: softleaf_from_pud had to be added and some other pud_* functions.

In a few words, this API goes through an address range and returns
whatever it is in there (swap/hwpoison/migration/marker entries, folios,
pfn and device entries, or nothing).

These are the internal return types the API uses:

PT_TYPE_NONE
PT_TYPE_FOLIO
PT_TYPE_MARKER
PT_TYPE_PFN
PT_TYPE_SWAP
PT_TYPE_MIGRATION
PT_TYPE_DEVICE
PT_TYPE_HWPOISON

The API also handles locking and batching itself, so the caller
does not really need to bother with that.

In order to handle contiguous-PMD mapped hugetlb pages, folio_pmd_batch,
which is an analogous of folio_pte_batch, has been implemented.

More information about the API can be found in patch #4.

This was tested on x86_64 and arm64, but as I said, it is still
incomplete, it has bugs and it still lacks some things (e.g: pte_hole functionality,
test_walk functionality),
therefore the RFC, to gather some initial feedback before investing more
time into this.

For now, only the /proc/pid/(smaps|numa_maps|pagemap) have been replaced
to use this new API.

Thanks in advance

Oscar Salvador (7):
mm: Add softleaf_from_pud
mm: Add {pmd,pud}_huge_lock helper
mm: Implement folio_pmd_batch
mm: Implement pt_range_walk
mm: Make /proc/pid/smaps use the new generic pagewalk API
mm: Make /proc/pid/numa_maps use the new generic pagewalk API
mm: Make /proc/pid/pagemap use the new generic pagewalk API

arch/arm64/include/asm/pgtable.h | 32 +
arch/loongarch/include/asm/pgtable.h | 1 +
arch/powerpc/include/asm/book3s/64/pgtable.h | 7 +
arch/s390/include/asm/pgtable.h | 38 +
arch/x86/include/asm/pgtable.h | 52 +
arch/x86/include/asm/pgtable_64.h | 2 +
arch/x86/mm/pgtable.c | 18 +-
fs/proc/task_mmu.c | 1369 +++++++-----------
include/asm-generic/pgtable_uffd.h | 15 +
include/linux/leafops.h | 46 +
include/linux/mm.h | 2 +
include/linux/mm_inline.h | 32 +
include/linux/pagewalk.h | 104 ++
include/linux/pgtable.h | 97 ++
mm/internal.h | 75 +-
mm/memory.c | 22 +
mm/pagewalk.c | 400 +++++
mm/pgtable-generic.c | 10 +
18 files changed, 1483 insertions(+), 839 deletions(-)

--
2.35.3