j.glisse@xxxxxxxxx writes: > From: Jérôme Glisse <jglisse@xxxxxxxxxx> > > The mmu_notifier_invalidate_range_start() and mmu_notifier_invalidate_range_end() > can be considered as forming an "atomic" section for the cpu page table update > point of view. Between this two function the cpu page table content is unreliable > for the address range being invalidated. > > Current user such as kvm need to know when they can trust the content of the cpu > page table. This becomes even more important to new users of the mmu_notifier > api (such as HMM or ODP). I don't see kvm using the new APIs in this patch. Also what is that HMM use this for, to protect walking of mirror page table ?. I am sure you are covering that in the later patches. May be you may want to mention the details here too. > > This patch use a structure define at all call site to invalidate_range_start() > that is added to a list for the duration of the invalidation. It adds two new > helpers to allow querying if a range is being invalidated or to wait for a range > to become valid. > > For proper synchronization, user must block new range invalidation from inside > there invalidate_range_start() callback, before calling the helper functions. > Otherwise there is no garanty that a new range invalidation will not be added > after the call to the helper function to query for existing range. > > Changed since v1: > - Fix a possible deadlock in mmu_notifier_range_wait_valid() > > Changed since v2: > - Add the range to invalid range list before calling ->range_start(). > - Del the range from invalid range list after calling ->range_end(). > - Remove useless list initialization. > -aneesh -- 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