Re: [PATCH v2 3/5] mm: Add RCU-based VMA lookup helper that waits for writers

On Fri, Jun 12, 2026 at 6:00 PM Vlastimil Babka (SUSE)
<[email protected]> wrote:
>
> On 6/11/26 01:04, Dave Hansen wrote:
> > From: Dave Hansen <[email protected]>
> >
> > == Background ==
> >
> > There are basically two parallel ways to look up a VMA: the
> > traditional way, which is protected by mmap_lock, and the RCU-based
> > per-VMA lock way which is based on RCU and refcounts.
> >
> > == Problem ==
> >
> > The mmap_lock one is more straightforward to use but it has a big
> > disadvantage in that it can not be mixed with page faults since those
> > can take mmap_lock for read, which can deadlock when mixed with page
> > faults. For example:
>
> ... mixed with nested page faults and parallel writers, perhaps?
>
> >
> >       mmap_read_lock(mm);
> >       // Another thread does mmap_write_lock().
> >       // New mmap_lock readers are blocked.
> >       vma = vma_lookup(mm, address);
> >       // This deadlocks on mmap_read_lock() if it faults:
> >       copy_from_user(address);
> >       mmap_read_unlock(mm);
> >
> > The RCU one can be mixed with faults, but it is not available in all
>
> I'd stick to the per-VMA lock term than "RCU one"
>
> > configs, so all RCU users need to be able to fall back to the
> > traditional way.
>
> This is now an obsolete statement as patch 1 makes them available? But the
> problem is that they can fail and using mmap read lock as a fallback in a
> simple way has the above issue?
>
> > == Solution ==
> >
> > Add a variant of the RCU-based lookup that waits for writers. This is
> > basically the same as the existing RCU-based lookup, but it also takes
> > mmap_lock for read and waits for writers to finish before returning
> > the VMA. This has some advantages:
>
> I would stress the part that the mmap lock is taken *only temporarily* to
> wait for the writers and ensure we obtain a per-vma read lock, and then
> dropped again? As that's the main trick IIUC.
>
> >  1. Callers do not need to have a fallback path for when they
> >     collide with writers.
> >  2. It can be used in contexts where page faults can happen because
> >     it can take the mmap_lock for read but never *holds* it.
> >  3. Its fast path does not require taking mmap_lock for read.
> >
> > Basically, when applied correctly, this approach results in faster
> > *and* simpler code.
> >
> > Signed-off-by: Dave Hansen <[email protected]>
> > Cc: Suren Baghdasaryan <[email protected]>
> > Cc: Andrew Morton <[email protected]>
> > Cc: "Liam R. Howlett" <[email protected]>
> > Cc: Lorenzo Stoakes <[email protected]>
> > Cc: Vlastimil Babka <[email protected]>
> > Cc: Shakeel Butt <[email protected]>
> > Cc: [email protected]
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Cc: Arve Hjønnevåg <[email protected]>
> > Cc: Todd Kjos <[email protected]>
> > Cc: Christian Brauner <[email protected]>
> > Cc: Carlos Llamas <[email protected]>
> > Cc: Alice Ryhl <[email protected]>
> > Cc: "David S. Miller" <[email protected]>
> > Cc: David Ahern <[email protected]>
> > Cc: [email protected]
> >
> > --
> >
> > Changes from v1:
> >  * Add a comment explaining that this can not be mixed with other
> >    per-VMA lock or mmap_lock users. It is prone to deadlocks if so.
> >  * Add a FIXME about making the mmap_read_lock() killable
>
> I don't see it anywhere?
>
> >  * Add more chaneglog bits about the possibility for an infinite goto
> >    loop.
> >  * Adopt vma_start_read_unlocked() implementation from Lorenzo
> > ---
> >
> >  b/include/linux/mmap_lock.h |    3 +++
> >  b/mm/mmap_lock.c            |   27 +++++++++++++++++++++++++++
> >  2 files changed, 30 insertions(+)
> >
> > diff -puN include/linux/mmap_lock.h~lock-vma-under-rcu-wait include/linux/mmap_lock.h
> > --- a/include/linux/mmap_lock.h~lock-vma-under-rcu-wait       2026-06-10 15:57:55.828431712 -0700
> > +++ b/include/linux/mmap_lock.h       2026-06-10 15:57:55.834431925 -0700
> > @@ -257,6 +257,9 @@ static inline bool vma_start_read_locked
> >       return vma_start_read_locked_nested(vma, 0);
> >  }
> >
> > +struct vm_area_struct *vma_start_read_unlocked(struct mm_struct *mm,
> > +                                            unsigned long address);
> > +
> >  static inline void vma_end_read(struct vm_area_struct *vma)
> >  {
> >       vma_refcount_put(vma);
> > diff -puN mm/mmap_lock.c~lock-vma-under-rcu-wait mm/mmap_lock.c
> > --- a/mm/mmap_lock.c~lock-vma-under-rcu-wait  2026-06-10 15:57:55.831431819 -0700
> > +++ b/mm/mmap_lock.c  2026-06-10 16:02:50.723860779 -0700
> > @@ -338,6 +338,33 @@ inval:
> >       return NULL;
> >  }
> >
> > +/*
> > + * Find the VMA covering 'address' and lock it for reading. Waits for writers to
> > + * finish if the VMA is being modified. Returns NULL if there is no VMA covering
> > + * 'address'.
> > + *
> > + * Use only in code paths where no mmap_lock and no VMA lock is held.
>
> I think we have various asserts that could be used and are stronger than a
> comment ;)

I'm working on a resping for this patchset (per Dave's request) and
I'm not sure which asserts we can use to assert that locks are *not*
held. I think that would be a racy assertion anyway (the lock might be
taken right after that assert) but maybe I'm wrong?

>
> > + *
> > + * The fast path does not take mmap_lock.
> > + */
> > +struct vm_area_struct *vma_start_read_unlocked(struct mm_struct *mm,
> > +                                            unsigned long address)
> > +{
> > +     struct vm_area_struct *vma;
> > +
> > +     /* Fast path: return stable VMA covering 'address': */
> > +     vma = lock_vma_under_rcu(mm, address);
> > +     if (vma)
> > +             return vma;
> > +
> > +     /* Slow path: preclude VMA writers by getting mmap read lock. */
>
> Again I would say "temporarily".
>
> > +     guard(rwsem_read)(&mm->mmap_lock);
>
> Aside from the missing vma_lookup() I'm not sure we should also trust the
> result of the lookup blindly? Should we also verify we found a vma? Some
> callers might not fail the lookup because they will only lookup something
> that's sure to be present, but some might fail?
>
> > +     if (!vma_start_read_locked(vma))
> > +             return NULL;
>
> You can count me on the side that would rather see explicit operations than
> the guard. Exactly because it's a subtle usage of the mmap sem, and yeah
> also the tracing that Suren pointed out.
>
> Seems to me uffd_lock_vma() mostly does all this right (but also does more
> stuff that we don't want to do). I'm just not sure right know when
> vma_start_read_locked() failures can happen in practice here (can it be only
> recfount overflow or also refcount being zero? hopefully not zero if we
> found the vma under mmap lock for read? comment in
> lock_next_vma_under_mmap_lock() seems to hint at that) and what to do about
> them. We seem to have some unhelpfully stale comments around.
>
> - uffd_lock_vma() doesn't document that it can return -EAGAIN. (and should
> the caller then retry or what?)
>
> - vma_start_read_locked() has a comment saying how it cannot fail, but it in
> fact can.

I'll modify the comments for these functions to be clearer and more complete.

>
> > +
> > +     return vma;
> > +}
> > +
> >  static struct vm_area_struct *lock_next_vma_under_mmap_lock(struct mm_struct *mm,
> >                                                           struct vma_iterator *vmi,
> >                                                           unsigned long from_addr)
> > _
>