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
