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 >
