mapping_wrprotect_range(9)

💅 mapping_wrprotect_range(9) ✨

okay so this is a page from the Kernel API Manual, and bestie, we are about to become intimately familiar with mapping_wrprotect_range. it's giving "niche kernel internals" and honestly? we're obsessed. 🫶

---

🌸 NAME 🌸

mapping_wrprotect_range — write-protect all mappings in a specified range. that's it, that's the whole vibe. 💖

---

✨ SYNOPSIS ✨

int mapping_wrprotect_range (struct address_space *mapping , pgoff_t
pgoff , unsigned long pfn , unsigned long nr_pages );

like, copy that exactly, no cap. every asterisk and comma matters, this is C, we don't freestyle. 😭

---

🎀 ARGUMENTS 🎀

so here's the cast of characters, and yes they all have main character energy:

• mapping — the struct address_space whose reverse mapping should be traversed. this is the map we're walking, iykyk. 🗺️
• pgoff — the page offset at which pfn is mapped within mapping. basically "where in the mapping does this page live". 📍
• pfn — the PFN of the page mapped in mapping at pgoff. PFN = page frame number, the physical-address bestie. 🔥
• nr_pages — the number of physically contiguous base pages spanned. so like, how many pages we're doing here. count 'em. 🧮

---

🦋 DESCRIPTION 🦋

okay so what does this actually do, you ask? it traverses the reverse mapping, finding all VMAs which contain a shared mapping of the pages in the specified range in mapping, and write-protects them. and "write-protects" here literally means it updates the page tables to mark the mappings read-only — such that a write protection fault arises when the mappings are written to. so like, the moment someone tries to write, boom, fault. that's the whole point. 💅

and now the important bit, pay attention bestie: the pfn value need not refer to a folio, but rather can reference a kernel allocation which is mapped into userland. so we therefore do not require that the page maps to a folio with a valid mapping or index field — instead, the caller specifies these in mapping and pgoff. the caller does the work. respect. 👑

ngl this is the part people get wrong — the folio assumption is not safe here, the caller has to hand you mapping and pgoff themselves. no guessing, no vibes-based lookups. 🙈

---

⭐ RETURN ⭐

the number of write-protected PTEs, or an error. short and sweet, love that for us. 🎀

---

🌈 SEE ALSO 🌈

the whole friend group, in Kernel file ./mm/rmap.c:

__anon_vma_prepare(9), anon_vma_clone(9), unlink_anon_vmas(9), page_address_in_vma(9), folio_referenced(9), pfn_mkclean_range(9), folio_move_anon_rmap(9), __folio_set_anon(9), __page_check_anon_rmap(9), folio_add_anon_rmap_ptes(9), folio_add_anon_rmap_pmd(9), folio_add_new_anon_rmap(9), folio_add_file_rmap_ptes(9), folio_add_file_rmap_pmd(9), folio_add_file_rmap_pud(9), folio_remove_rmap_ptes(9), folio_remove_rmap_pmd(9), folio_remove_rmap_pud(9), try_to_unmap(9), try_to_migrate(9), make_device_exclusive(9), __rmap_walk_file(9).

like, that's the entire rmap.c cinematic universe and we stan. 🍓

---

and that's the page, bestie!! sourced from ./mm, dated October 2026, and it's mapping_wrprotect_range(9) all the way down. go forth and write-protect responsibly 💜✨