VM_MAP_WIRE(9)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1

πŸ’œ vm_map_wire β€” bestie's guide to pinning pages down (kernel developer's manual, section 9)

okay so real talk, this page is vm_map_wire and vm_map_unwire β€” the two functions that manage page wiring inside a virtual memory map. it's giving "i'm gonna make sure these pages cannot leave" energy and honestly? iconic. ✨


🌸 NAME 🌸

vm_map_wire, vm_map_unwire β€” manage page wiring within a virtual memory map 🫢


πŸŽ€ SYNOPSIS πŸŽ€

like always, you gotta bring the right headers to the party first, no cap:

#include <sys/param.h>
#include <vm/vm.h>
#include <vm/vm_map.h>

then the functions themselves, here's the whole fit:

int
vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end,
    int flags);

int
vm_map_unwire(vm_map_t map, vm_offset_t start, vm_offset_t end,
    int flags);

πŸ¦‹ DESCRIPTION πŸ¦‹

so vm_map_wire() is the main character here πŸ’… β€” its whole job is wiring up the pages in the range between start and end inside the map map. and what does "wired" even mean? it means those pages are locked into physical memory, and they may not be paged out as long as their wire count stays above zero. periodt. πŸ”’

then vm_map_unwire() does the corresponding unwire operation β€” the reverse vibe, the undoing, the "okay you can breathe now" moment. 🧚

the flags argument is a bit mask, made of these flags right here:

  • if the VM_MAP_WIRE_USER flag is set, the function operates within user address space πŸ‘‘
  • if the VM_MAP_WIRE_HOLESOK flag is set, it may operate upon an arbitrary range within the address space of map πŸ•³οΈβœ¨
  • if you actually want a contiguous range, you should explicitly express your intent by specifying the VM_MAP_WIRE_NOHOLES flag β€” say it with your chest, bestie πŸ“£

🌈 IMPLEMENTATION NOTES 🌈

both functions are gonna try to grab a lock on the map using vm_map_lock(9), and they hold onto it for the whole duration of the call. like, the entire time. 🫰

and if they detect MAP_ENTRY_IN_TRANSITION, they'll call vm_map_unlock_and_wait(9) until the map becomes available again β€” just politely waiting in the group chat until it's their turn 😭

⚠️ important vibe check: the map could have changed during that window, because somebody else was holding it. so if you're consuming this interface, you should be checking for that condition using the return values down below. don't skip this, fr fr πŸ’€

⭐ RETURN VALUES ⭐

vm_map_wire() and vm_map_unwire() have identical return values β€” twins, matching outfits, the whole thing πŸ‘―

  • KERN_SUCCESS β€” returned if all the pages within the range were [un]wired successfully πŸŽ‰ slay
  • KERN_INVALID_ADDRESS β€” returned otherwise: if the specified range was not valid, or if the map changed while the MAP_ENTRY_IN_TRANSITION flag was set 🚩

πŸ”₯ SEE ALSO πŸ”₯

go read those too, iykyk πŸ“š


πŸ’– AUTHORS πŸ’–

this manual page was written by Bruce M Simpson <bms@spc.org> β€” ty for your service king πŸ«‘πŸ‘‘


and that's the whole page bestie, no notes πŸ’…

sign-off szn: this one came from Debian, dated July 19, 2003 β€” a whole vintage moment, honestly kinda nostalgic πŸŽ€βœ¨ mwah, go wire some pages responsibly πŸ¦‹πŸ’œ

πŸ“¦ where this page comes from