[PATCH 00/13] mmu_notifier kill invalidate_page callback

[Felix Kuehling]

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