kvfree_rcu_barrier(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– kvfree_rcu_barrier πŸ’–

okay bestie, welcome to the kvfree_rcu_barrier(9) page β€” that's the kernel API manual, section 9, and yes we're gonna get through it together 🫢


✨ NAME ✨

kvfree_rcu_barrier β€” literally just sits there and waits until every single in-flight kvfree_rcu() call has finished. no cap. it's the "hold on, everyone get in the car before we leave" of kernel functions πŸš—πŸ’¨


✨ SYNOPSIS ✨

void kvfree_rcu_barrier (void );

that's it. that's the whole vibe check. πŸ‘‘


✨ ARGUMENTS ✨

  • void β€” no arguments. nada. zero. she takes nothing and gives you patience 🌸

✨ DESCRIPTION ✨

okay so listen, this part is important so put your phone down for a sec πŸ™ˆ

a single argument of a kvfree_rcu call has a slow path. that slow path triggers a synchronize_rcu and then frees the pointer. and the way that it is done β€” it's done before the return from the function. so like, by the time you get back out of the call, that whole sequence already happened ✨

so because of that: for any single-argument call that will result in a kfree to a cache that is going to be destroyed during module exit, it is the developer's responsibility to make sure all of those calls have returned before the call to kmem_cache_destroy. πŸ’…

bestie this is on YOU. nobody's coming to save you. if you kmem_cache_destroy while those calls are still in flight, that's a you problem 😭 please make sure they returned first, fr fr.

✨ SEE ALSO ✨

go check these out, they're all in the kernel file ./mm/slab_common.c πŸ›βœ¨


aaaand that's the page! πŸŽ€ little sign-off for you: this one lives in ./mm, it's the October 2026 version, and the whole thing is the kvfree_rcu_barrier(9) page from your Kernel API Manual. go forth and wait for your in-flight calls before you destroy that cache, icon πŸ’œπŸ¦‹

πŸ“¦ where this page comes from