Re: [Patch] mmu_notifiers destroyed by __mmu_notifier_release()retain extra mm_count.

[Andrea Arcangeli]

On Fri, Feb 06, 2009 at 02:38:05AM +0100, Andrea Arcangeli wrote:
> It all boils down if unregister is mandatory or not. If it's mandatory

Oh I just found I documented it too!! ;)

/*
 * Must not hold mmap_sem nor any other VM related lock when calling
 * this registration function. Must also ensure mm_users can't go down
 * to zero while this runs to avoid races with mmu_notifier_release,
 * so mm has to be current->mm or the mm should be pinned safely such
 * as with get_task_mm(). If the mm is not current->mm, the mm_users
 * pin should be released by calling mmput after mmu_notifier_register
 * returns. mmu_notifier_unregister must be always called to
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 * unregister the notifier. mm_count is automatically pinned to allow
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 * mmu_notifier_unregister to safely run at any time later, before or 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* after exit_mmap. ->release will always be called before exit_mmap
 * frees the pages.
 */

So in short the current code has no bugs and the fact you have to call
unregister is intentional. Not patch required unless you request to
change API. If you don't call unregister mm will be leaked,
simply. For a moment I thought unregister wasn't mandatory because at
some point in one of the dozen versions of the api it wasn't, but in
the end I thought having an mm_count auto-pinning leaving no window
for corrupted mmu_notifier list was preferable ;).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/