unmap_vmas(9)

📦 version 7.3.1, in nixpkgs unstable

💅 unmap_vmas — a Kernel API Manual moment ✨

okay so bestie, welcome to the unmap_vmas page 🎀 this one lives in the Kernel API Manual, and it's giving "quiet but crucial" energy, iykyk.

🌸 NAME 🌸

unmap_vmas — unmap a range of memory covered by a list of vma's 💖

lowkey the whole personality in one line, no cap.

✨ SYNOPSIS ✨

void unmap_vmas (struct mmu_gather *tlb , struct unmap_desc *unmap );

literally that's the whole call, and it returns void — she does the work and doesn't even ask for a thank-you 🫶

🦋 ARGUMENTS 🦋

  • tlb — the address of the caller's struct mmu_gather, bestie. that's your caller's own gather struct, and yes, you're handing over its address 💅
  • unmap — The unmap_desc. that's it, that's the whole description, she's mysterious like that 🙈

👑 DESCRIPTION 👑

so the main character task: unmap all pages in the vma list. all of them. every single one 🔥

but listen — only addresses between start and end will be unmapped. like, that's the boundary, respect it ✋

⭐ important vibe check: the VMA list must be sorted in ascending virtual address order. not optional. not "eh, close enough." sorted. periodt 💀

and here's the part you cannot skip, bestie: unmap_vmas assumes that the caller will flush the whole unmapped address range after unmap_vmas returns. so the only responsibility here is to make sure that any thus-far unmapped pages are flushed before unmap_vmas drops the lock and schedules. that's the whole deal — don't leave those pages hanging, flush them first, then she drops the lock and schedules 🧚✨

🌈 SEE ALSO 🌈

Kernel file ./mm/memory.c — and here's the full squad, no one left behind 💜:

and that's the page, bestie 🍓 ty for reading, mwah 💋 this gem came out of ./mm in October 2026 — catch you on the next one, slay 💖✨

📦 where this page comes from