kasan_mempo...oison_object(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… kasan_mempo...oison_object(9) πŸ’…

okay so this is a page from the Kernel API Manual, and the star of the show is kasan_mempool_unpoison_object. yes it's a mouthful, no we're not gonna shorten it, it's iconic and it knows it 🫢


✨ NAME ✨

kasan_mempool_unpoison_object β€” unpoison a mempool slab allocation, bestie. that's the whole vibe. πŸŽ€


🌸 SYNOPSIS 🌸

void kasan_mempool_unpoison_object (void *ptr , size_t size );

literally just those two args, no cap.


πŸ¦‹ ARGUMENTS πŸ¦‹

  • ptr β€” pointer to the slab allocation. the actual thing you're unpoisoning. πŸ’–
  • size β€” how much of it you want unpoisoned. the size to be unpoisoned, fr fr.

⭐ DESCRIPTION ⭐

okay so picture this: this function is intended for kernel subsystems that cache slab allocations so they can reuse them instead of freeing them back to the slab allocator (e.g. mempool). they're hoarding their little allocations like a girl hoarding scrunchies and honestly? valid. πŸ‘‘

what it does is unpoison a slab allocation that was previously poisoned via kasan_mempool_poison_object, and it saves an alloc stack trace for it β€” without initializing the allocation's memory. so like, the memory stays exactly as it was, no glow-up, no reset, nothing. πŸ™ˆ

and for the tag-based modes? this function does not assign a new tag to the allocation. instead it restores the original tags based on the pointer value. the way it just puts the old tags back on like a cute throwback outfit. πŸ’…

also important: this thing operates on all slab allocations, including large kmalloc allocations β€” i.e. the ones backed directly by the buddy allocator rather than kmalloc slab caches. every single one. no allocation left behind. ✨


πŸ”₯ SEE ALSO πŸ”₯

kernel file ./include/linux/kasan.h, plus the whole friend group:


pro tip from me to you: kasan_mempool_unpoison_object and kasan_mempool_poison_object are literally a matching set, so if you're calling one you're probably calling the other. iykyk πŸ’€

and that's the whole page!! sourced from ./include/linux, dated October 2026, filed under kasan_mempo...oison_object(9) β€” mwah, slay, go read your kernel headers, ily, bye πŸ§šπŸ’œπŸŒˆ

πŸ“¦ where this page comes from