walk_page_range(9)

🌸 walk_page_range (9) — Kernel API Manual 🌸

ok so bestie, gather round, because today we're talking about walk_page_range, and it literally walks the page table with callbacks you get to define yourself. main character energy fr fr 💅

---

✨ NAME ✨

walk_page_range — walk page table with caller specific callbacks 🚶♀️🦋

---

🎀 SYNOPSIS 🎀

int walk_page_range (struct mm_struct *mm , unsigned long start ,
       unsigned long end , const struct mm_walk_ops *ops , void *private );

---

💖 ARGUMENTS 💖

• mm — the mm_struct that represents the target process whose page table we're gonna walk, no cap
• start — start address of the virtual address range 👑
• end — end address of the virtual address range 🌈
• ops — the operation to call during the walk
• private — private data for callbacks' usage (your little secret stash 🫶)

---

🌟 DESCRIPTION 🌟

So here's the vibe: we recursively walk the page table tree of the process represented by mm, inside the virtual address range [start, end). During the walking, we can do some caller-specific works for each entry, by setting up pmd_entry, pte_entry, and/or hugetlb_entry. And if you don't set up for some of these callbacks? The associated entries/pages are just ignored — not ignored in a mean way, they just get skipped 💀.

The return values of these callbacks are commonly defined like below:

• 0 : succeeded to handle the current entry, and if you don't reach the end address yet, continue to walk. ✅
• >0 : succeeded to handle the current entry, and return to the caller with caller specific value. 🔥
• <0 : failed to handle the current entry, and return to the caller with error code. 😭

Before starting to walk page table, some callers want to check whether they really want to walk over the current vma, typically by checking its vm_flags. walk_page_test and ops->test_walk are used for this purpose, bestie — a little vibe check before the main event ✨.

If operations need to be staged before and committed after a vma is walked, there are two callbacks, pre_vma and post_vma. Note that post_vma, since it is intended to handle commit-type operations, can't return any errors — like, it literally cannot, so don't try it 🙈.

struct mm_walk keeps current values of some common data like vma and pmd, which are useful for the access from callbacks. And if you want to pass some caller-specific data to callbacks, private should be helpful — that's literally what it's there for 💜.

Locking: Callers of walk_page_range and walk_page_vma should hold mm->mmap_lock, because these function traverse vma list and/or access to vma's data. this is NOT optional, bestie, hold the lock fr fr 🔒

---

🦋 SEE ALSO 🦋

Kernel file ./mm/pagewalk.c — walk_kernel_page_table_range(9), walk_page_range_debug(9), walk_page_mapping(9), folio_walk_start(9). go read them, iykyk 👑

---

ok that's the whole page, you ate that 💅 from ./mm, October 2026 — stay iconic, hold your locks, and see you in the page tables 🎀✨