On Tue, Jul 08, 2014 at 06:00:00PM -0400, j.glisse@xxxxxxxxx wrote: > From: Jérôme Glisse <jglisse@xxxxxxxxxx> > > The event information will be usefull for new user of mmu_notifier API. > The event argument differentiate between a vma disappearing, a page > being write protected or simply a page being unmaped. This allow new > user to take different path for different event for instance on unmap > the resource used to track a vma are still valid and should stay around. > While if the event is saying that a vma is being destroy it means that any > resources used to track this vma can be free. > > Changed since v1: > - renamed action into event (updated commit message too). > - simplified the event names and clarified their intented usage > also documenting what exceptation the listener can have in > respect to each event. > > Changed since v2: > - Avoid crazy name. > - Do not move code that do not need to move. Okay, I can actually see use-cases for something like this. Given the number of invalidate_range_start/end call-sites and the semantics of these call-backs it would allow certain optimizations to know details of whats going on between these calls. But why do you need this event information for all the other mmu_notifier call-backs? In change_pte for example you already get the address and the new pte value, isn't that enough to find out whats going on? Joerg -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>