folio_release_kmap(9)

📦 version 7.3.1, in nixpkgs unstable

💅 folio_release_kmap — from the Kernel API Manual, bestie ✨

Okay so real talk, this one's a little function with big "clean up after yourself" energy, and honestly? Iconic behavior. It lives in the Kernel API Manual and it's here to unmap a folio and drop a refcount. Two jobs, one function, main character energy fr fr. 🫶

✨ SYNOPSIS ✨

void folio_release_kmap (struct folio *folio , void *addr );

Returns nothing (void), takes two args, does exactly what it says on the tin. No notes. 💅

🎀 ARGUMENTS 🎀

  • folio — the folio you're releasing. Say bye to it, bestie. 👋
  • addr — the address that a previous call to kmap_local_folio handed back to you. Like, the exact one. Don't be out here making up addresses. 🙈

🌸 DESCRIPTION 🌸

So the vibe here is: it's super common (directory handling is the classic example, iykyk) to kmap a folio. You map it, you poke at it, you do your little tasks. Gorgeous. But then somebody has to clean up, and that somebody is this function. 💖

What it does: it unmaps the folio, and it drops the refcount that was being held to keep the folio alive while we were accessing it. Both. Together. One call. Slay. ✨

Lowkey the whole point is that you don't leak a refcount by forgetting the second half — this bad boy handles the pair for you. 🧚

🔥 SEE ALSO 🔥

All the siblings and cousins, in the order the page gives them, no cap:

Kernel file ./include/linux/highmem.h:

Like, the whole highmem friend group showed up to the group chat. Obsessed. 🌈

Alright bestie, that's the whole page 🦋 — this lil gem comes to you from ./include/linux and it's stamped October 2026, so go forth, release those kmaps, drop those refcounts, and remember: always clean up your mappings. Periodt. 💜🎀⭐

📦 where this page comes from