clean_recor...apping_range(9)

🌸 clean_record_shared_mapping_range(9) — from the Kernel API Manual 💅

okay so bestie, welcome to the glow-up of clean_record_shared_mapping_range(9), straight out of the Kernel API Manual. this one's a mm/mapping_dirty_helpers star and she is booked and busy. let's get into it 🫶

---

✨ NAME ✨

clean_record_shared_mapping_range — clean and record every single pte in an address space range. yes, both. multitasking queen 👑

---

🦋 SYNOPSIS 🦋

unsigned long clean_record_shared_mapping_range (struct address_space
*mapping , pgoff_t first_index , pgoff_t nr , pgoff_t bitmap_pgoff ,
unsigned long *bitmap , pgoff_t *start , pgoff_t *end );

like, look at that signature. seven whole arguments. she's high-maintenance and we respect it 💅

---

🎀 ARGUMENTS 🎀

• mapping — the address_space we want to clean. the main character of this whole operation ✨
• first_index — the first page offset in the range. where the party starts 🎉
• nr — how many incremental page offsets we're covering. literally the guest count.
• bitmap_pgoff — the page offset of the first bit in bitmap. yes, bits have an offset too, iykyk.
• bitmap — pointer to a bitmap of at least nr bits. important!! the bitmap needs to cover the whole range first_index..first_index + nr. no half-covering, no gaps, we're not doing that 🙈
• start — pointer to the number of the first set bit in bitmap. it gets modified as new bits are set by the function.
• end — pointer to the number of the last set bit in bitmap. none set. the value is modified as new bits are set by the function.

---

💖 DESCRIPTION 💖

so when this function returns, there is no guarantee that a CPU hasn't already dirtied new ptes. (rude, but okay.) however — and this is the key part — it will not clean any ptes not reported in the bitmap. so, what are the guarantees? glad you asked bestie, here's the list:

• All ptes dirty when the function starts executing will end up recorded in the bitmap. slay, no cap 🔥
• All ptes dirtied after that will either remain dirty, be recorded in the bitmap, or both. flexible queen 🌈

okay so if a caller needs to be sure all dirty ptes are picked up and none extra get added, they've gotta put in the work: first write-protect the address-space range and make sure new writers are blocked in page_mkwrite or pfn_mkwrite. and then, after a TLB flush following the write-protection, pick up all the dirty bits. no shortcuts, bestie 😤

also ngl, this function currently skips transhuge page-table entries, since it's intended for dirty-tracking on the PTE level. it will warn on encountering transhuge dirty entries though 👀 and it can easily be extended to handle them as well. future upgrade potential, we love to see it ⭐

---

👑 RETURN 👑

the number of dirty ptes actually cleaned. that's it, that's the number 💀

---

🧚 SEE ALSO 🧚

• Kernel file ./mm/mapping_dirty_helpers.c — the source, the origin story 💜
• struct wp_walk(9)
• wp_pte(9)
• struct clean_walk(9)
• clean_record_pte(9)
• wp_shared_mapping_range(9)

go read them, they're iconic, fr fr 📚

---

✨ and that's the whole page!! sourced from ./mm, dated October 2026, and filed under clean_recor...apping_range(9) — yes the header literally abbreviates it like that, we don't make the rules 🎀 bye bestie, go clean some ptes 💅🌸