Re: using range locks instead of mm_sem

[Laurent Dufour <ldufour@linux.vnet.ibm.com>]

On 22/08/2018 16:46, Davidlohr Bueso wrote:
> 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.

I think the range locked should be aligned to the underlying VMA plus one page
on each side to prevent that VMA to be merged.
But this raises a concern with the VMA merging mechanism which tends to limit
the number of VMAs and could lead to a unique VMA, limiting the advantage of a
locking based on the VMA's boundaries.

>>
>> 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
>