Hi Jérôme, I have some questions about the potential range-start-end race you mentioned. On 2017-08-29 07:54 PM, Jérôme Glisse wrote: > Note that a lot of existing user feels broken in respect to range_start/ > range_end. Many user only have range_start() callback but there is nothing > preventing them to undo what was invalidated in their range_start() callback > after it returns but before any CPU page table update take place. > > The code pattern use in kvm or umem odp is an example on how to properly > avoid such race. In a nutshell use some kind of sequence number and active > range invalidation counter to block anything that might undo what the > range_start() callback did. What happens when we start monitoring an address range after invaligate_range_start was called? Sounds like we have to keep track of all active invalidations for just such a case, even in address ranges that we don't currently care about. What are the things we cannot do between invalidate_range_start and invalidate_range_end? amdgpu calls get_user_pages to re-validate our userptr mappings after the invalidate_range_start notifier invalidated it. Do we have to wait for invalidate_range_end before we can call get_user_pages safely? Regards, Felix
