kasan_mempoo...poison_pages(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… kasan_mempool_unpoison_pages(9) β€” from the Kernel API Manual, bestie ✨

okay so picture this: it's the Kernel API Manual, the function is kasan_mempool_unpoison_pages, and you're about to understand it. we're doing this together, no cap 🫢


🌸 NAME 🌸

kasan_mempool_unpoison_pages β€” literally unpoisons a mempool page allocation. that's the whole vibe. πŸ’–


✨ SYNOPSIS ✨

void kasan_mempool_unpoison_pages (struct page *page , unsigned int
order );

yep, that's it, that's the whole signature. copy it exact, don't get creative with the semicolons, i'm begging πŸ™ˆ


πŸŽ€ ARGUMENTS πŸŽ€

  • page β€” a pointer to the page allocation. like, the actual pages we're talking about here. main character energy πŸ‘‘
  • order β€” the order of the allocation. it's a unsigned int and it's telling you the size/shape of what we're working with, bestie πŸ¦‹

🧚 DESCRIPTION 🧚

so this function is intended for kernel subsystems that cache page allocations so they can reuse them instead of freeing them back to page_alloc β€” like, for example, mempool. it's giving "i have a stash and i'm not giving it up" πŸ’€

what it actually does: it unpoisons a page allocation that was previously poisoned by kasan_mempool_poison_pages, and it does this without zeroing the allocation's memory. read that again. no zeroing. the memory is untouched. periodt πŸ”₯

and for the tag-based modes, this function assigns a new tag to the allocation. fresh tag, fresh me, slay 🌈

ngl this is the kind of function that only makes sense if you already know the poisoning system, but the details are the details and i refuse to drop a single one πŸ’…

⭐ SEE ALSO ⭐


and that's the page!! πŸ“ this whole thing lives in ./include/linux, it's dated October 2026, and it's filed under kasan_mempoo...poison_pages(9) (yes the truncation is real, yes it bugs me too, no i can't fix it 😭). bye bestie, go poison responsibly πŸ’œ

πŸ“¦ where this page comes from