folio_add_anon_rmap_ptes(9)

📦 version 7.3.1, in nixpkgs unstable

🌸 folio_add_anon_rmap_ptes(9) — the kernel API manual, but make it make sense 🌸

okay so bestie, we're in the Kernel API Manual today and the function we're stanning is folio_add_anon_rmap_ptes. it's giving very much "plumbing but make it couture" 💅 let's get into it.

✨ NAME ✨

folio_add_anon_rmap_ptes — the girl whose whole job is adding PTE mappings to a page range of an anon folio. periodt. 🎀

🦋 SYNOPSIS 🦋

void folio_add_anon_rmap_ptes (struct folio *folio , struct page *page ,
int nr_pages , struct vm_area_struct *vma , unsigned long address ,
rmap_t flags );

that's the whole signature, no cap. copy it exactly, don't get creative 💖

👑 ARGUMENTS 👑

  • folio — the folio we're adding the mappings to. she's the main character here 🫶
  • page — the first page to add. like, the starting point of the whole situation ✨
  • nr_pages — the number of pages that will be mapped. the headcount, basically 🔥
  • vma — the vm area in which the mappings get added 🌸
  • address — the user virtual address of the first page to map. where it all goes down 📍
  • flags — the rmap flags. yes queen, flags 🎀

💜 DESCRIPTION 💜

so the page range of folio is defined by [first_page, first_page + nr_pages) — that half-open bracket situation, iykyk 🧚

now the important part, and not me being dramatic, this is literally required:

the caller needs to hold the page table lock 🔒

and in the anon_vma case, the page must be locked. why? two reasons and they're both real:

  • to serialize the mapping,index checking after setting 👀
  • to ensure that an anon folio is not being upgraded racily to a KSM folio (but KSM folios are never downgraded — love that for them, no take-backsies 💀)

🍓 SEE ALSO 🍓

kernel file ./mm/rmap.c and the whole friend group:

go read them all, bestie, it's a whole syllabus 📚✨

🌈 and that's the page! this one came from the ./mm source, dated October 2026 — so go forth, hold that page table lock, and slay 💅💖
📦 where this page comes from