Re: [PATCH 0/6] mm: Make per-VMA locks available in all builds

[Suren Baghdasaryan]

On Fri, May 8, 2026 at 10:01 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> On 5/8/26 09:52, Lorenzo Stoakes wrote:
> ...
> >>  * Can the helper avoid the goto, maybe by taking the VMA refcount
> >>    while holding mmap_lock?
> >
> > Surely that'd defeat the purpose of VMA locks though? you'd hold the mmap lock
> > for less time but you're still contending vs. _any_ VMA write locks whilst
> > trying to get a VMA read lock?
> >
> > Unless it's on a slow path... hmm :)
>
> Yup. It's in a slow path. the example helper I had here does:
>
> retry:
>         vma = lock_vma_under_rcu(mm, address);
>         if (vma)
>                 return vma;
>         mmap_read_lock(mm);
>         vma = vma_lookup(mm, address);
>         mmap_read_unlock(mm);
>         goto retry;
>
> It avoids mmap_lock in the common, fast case. I was hoping to replace it
> with something like:
>
>         vma = lock_vma_under_rcu(mm, address);
>         if (vma)
>                 return vma;
>         mmap_read_lock(mm);
>         vma = vma_lookup(mm, address);
>         vma_start_read(vma->vm_mm, vma); // Is this safe?

It is safe if you use vma_start_read_locked() instead. That fallback
part is very similar to lock_next_vma_under_mmap_lock() but instead of
locking the next VMA you are locking the VMA at a given address.
uffd_lock_vma() is very close to the whole operation you described
here.

>         mmap_read_unlock(mm);
>         return vma;
>
> Which still uses mmap_lock, but avoids the goto. I'm pretty sure the
> first one doesn't have any locking problems. The second one, I need to
> think about a _lot_ more.
>
>