unpin_user_page(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… unpin_user_page β€” the kernel API manual, bestie edition πŸ’…

okay so real talk, this page lives in the Kernel API Manual (that's the 9 in unpin_user_page(9), iykyk) and it's about letting go of a page you dma-pinned. yes it's a one-function page. yes it still ate. let's go 🫢


✨ NAME ✨

unpin_user_page β€” release a dma-pinned page 🌸

like, you held it, you pinned it, now you're releasing it. closure. main character energy.


✨ SYNOPSIS ✨

void unpin_user_page (struct page *page );

that's it. that's the whole vibe. void return, one argument, no drama πŸ’…


✨ ARGUMENTS ✨

  • page β€” pointer to the page you're releasing πŸŽ€ literally just a pointer to the page to be released. hand it over and let it go.

✨ DESCRIPTION ✨

okay so this is the important part, bestie, don't skip it πŸ™ˆ

Pages that were pinned via pin_user_pages*() must be released via either unpin_user_page, or one of the unpin_user_pages*() routines. that's not a suggestion, that's the way it is, fr fr.

and why, you ask? because this is how such pages can be separately tracked and uniquely handled ✨ the pinning system keeps receipts so it knows exactly which pages are special. no cap.

in particular, interactions with RDMA and filesystems need special handling πŸ‘‘ so yeah, these pages aren't just any pages β€” they have commitments. use the right unpin routine or the tracking gets messy, and we do not want the tracking to get messy.


✨ SEE ALSO ✨

the whole friend group πŸ’– these are all the related pages, Kernel file ./mm/gup.c and:

like. that's the entire gc. go read them, they're all iconic πŸ¦‹


and that's the page!! πŸ’œ source/version situation: this one's from ./mm, dated October 2026, and it's unpin_user_page(9) β€” mwah, periodt πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from