mmu_notifier_put(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… mmu_notifier_put(9) πŸ’…

okay so bestie, welcome to the Kernel API Manual β€” this one's mmu_notifier_put, and it's genuinely one of those "every get needs a put" situations, you know the vibe 🫢


✨ NAME ✨

mmu_notifier_put β€” release the reference on the notifier πŸŽ€


✨ SYNOPSIS ✨

void mmu_notifier_put(struct mmu_notifier *subscription);

✨ ARGUMENTS ✨

  • subscription β€” the notifier we're acting on, like, the whole point of the call πŸ’–

✨ DESCRIPTION ✨

okay so here's the tea β˜• β€” this function must be paired with each mmu_notifier_get, fr fr. It releases the reference that the get handed you. And if this happens to be the last reference? Then the process to free the notifier gets run asynchronously. not immediately, not right now, asynchronously. she'll get to it πŸ’…

Now, <rainbow>unlike mmu_notifier_unregister</rainbow>, the get/put flow only calls ops->release when the mm_struct is destroyed. instead, free_notifier is always called to release any resources held by the user. so yeah, free_notifier is the reliable one here πŸ‘‘

And because ops->release is not guaranteed to be called, the user has to make sure that all sptes are dropped, and that no new sptes can be established before mmu_notifier_put is called. like, that part is on you, bestie, no cap πŸ™ˆ

heads up: this function can be called from the ops->release callback β€” but even then, the caller must still ensure it's called pairwise with mmu_notifier_get. the pairing rule does not get a day off 😀

Also!! modules calling this function must call mmu_notifier_synchronize in their __exit functions to ensure the async work is completed. don't skip it, that's not a vibe πŸ’€


✨ SEE ALSO ✨

Kernel file ./mm/mmu_notifier.c πŸ’– and also:


and that's the whole page, periodt 🌸 this cutie lives in ./mm, October 2026 edition β€” go forth and pair your gets and puts, icon πŸ¦‹πŸ’œ

πŸ“¦ where this page comes from