Re: using range locks instead of mm_sem

[Davidlohr Bueso <dave@stgolabs.net>]

On Wed, 22 Aug 2018, Shady Issa wrote:

>
>Hi Davidlohr,
>
>I am interested in the idea of using range locks to replace mm_sem. I 
>wanted to
>start trying out using more fine-grained ranges instead of the full 
>range acquisitions
>that are used in this patch (https://lkml.org/lkml/2018/2/4/235). 
>However, it does not
>seem straight forward to me how this is possible.
>
>First, the ranges that can be defined before acquiring the range lock 
>based on the
>caller's input(i.e. ranges supplied by mprotect, mmap, munmap, etc.) 
>are oblivious of
>the underlying VMAs. Two non-overlapping ranges can fall within the 
>same VMA and
>thus should not be allowed to run concurrently in case they are writes.

Yes. This is a _big_ issue with range locking the addr space. I have yet
to find a solution other than delaying vma modifying ops to avoid the races,
which is fragile. Obviously locking the full range in such scenarios cannot
be done either.

>
>Second, even if ranges from the caller function are aligned with VMAs, 
>the extent of the
>effect of operation is unknown. It is probable that an operation 
>touching one VMA will
>end up performing modifications to the VMAs rbtree structure due to 
>splits, merges, etc.,
>which requires the full range acquisition and is unknown beforehand.

Yes, this is similar to the above as well.

>
>I was wondering if I am missing something with this thought process, 
>because with the
>current givings, it seems to me that range locks will boil down to 
>just r/w semaphore.
>I would also be very grateful if you can point me to any more recent 
>discussions regarding
>the use of range locks after this patch from February.

You're on the right page.

Thanks,
Davidlohr