unmap_mapping_folio(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ unmap_mapping_folio ✨

okay so bestie, this is a page from the Kernel API Manual and it's about one (1) folio getting yeeted out of everybody's address space πŸŽ€ literally the "you don't have to go home but you can't stay here" of memory management πŸ’…


🌸 NAME 🌸

unmap_mapping_folio β€” unmap a single folio from processes. That's it. One folio. Unmapped. Periodt. ✨


πŸ¦‹ SYNOPSIS πŸ¦‹

void unmap_mapping_folio (struct folio *folio );

the way it just takes one argument and returns void… lowkey iconic 🫢


πŸ’– ARGUMENTS πŸ’–

  • folio β€” the locked folio that's about to be unmapped πŸ‘‘ heads up though: it's locked, bestie, so don't come in here without holding that lock, iykyk πŸ”’

🧚 DESCRIPTION 🧚

okay so picture this: this folio is mmaped into some userspace process somewhere, right? and unmap_mapping_folio goes and unmaps it from any userspace process that still has it mmaped. no survivors. no cap. πŸ’€

typically β€” and this is the efficiency era of it all β€” the range of nearby pages has already been unmapped, by unmap_mapping_pages or by unmap_mapping_range. so usually the bulk of the work is done and this is just the cleanup girlie ✨

but here's the plot twist 😭 once truncation or invalidation holds the lock on a folio, it might find that the page has been remapped again. like, it came back?? rude?? and that's exactly when it reaches for unmap_mapping_folio to unmap it finally. last one out, turn off the lights πŸ•―οΈ


🌈 SEE ALSO 🌈

so many references, bestie, this page has main character energy in the cross-reference department πŸ‘‘ all from the kernel file ./mm/memory.c:

like… that's a whole friend group 🫢 go read them, they're all slaying in their own way πŸ’œ


ok and one lil sign-off πŸ’Œ this page lives in ./mm, dated October 2026, and if you ever need to find it again it's filed under unmap_mapping_folio(9). mwah, go touch some pages πŸ“βœ¨
πŸ“¦ where this page comes from