Re: [PATCH v3 1/5] mm: Make per-VMA locks available universally

On Mon, Aug 3, 2026 at 9:08=E2=80=AFAM Lorenzo Stoakes (ARM) <[email protected]=
g> wrote:
>
> On Mon, Aug 03, 2026 at 08:24:44AM -0700, Suren Baghdasaryan wrote:
> > On Sun, Aug 2, 2026 at 2:55=E2=80=AFPM Suren Baghdasaryan <surenb@googl=
e.com> wrote:
> > >
> > > From: Dave Hansen <[email protected]>
> > >
> > > The per-VMA locks have been around for several years. They've had som=
e
> > > bugs worked out of them and have seen quite wide use. However, they
> > > are still only available when architectures explicitly enable them.
> > > Remove the conditional compilation around the per-VMA locks, making
> > > them available on all architectures and configs.
> > >
> > > The approach up to now seemed to be to add ARCH_SUPPORTS_PER_VMA_LOCK
> > > when the architecture started using per-VMA locks in the fault
> > > handler. But, contrary to the naming, the Kconfig option does not
> > > really indicate whether the architecture supports per-VMA locks or
> > > not. It is more of a marker for whether the architecture is likely to
> > > benefit from per-VMA locks.
> > >
> > > To me, the most important thing side-effect of universal availability
> > > is letting per-VMA locks be used in SMP=3Dn configs. This lets us use
> > > per-VMA locking in all x86 code without fallbacks.
> > >
> > > Overall, this just generally makes the kernel simpler. Just look at
> > > the diffstat. It also opens the door to users that want to use the
> > > per-VMA locks in common code. Doing *that* brings additional
> > > simplifications.
> > >
> > > The downside of this is adding some fields to vm_area_struct and
> > > mm_struct. There are likely ways to optimize this, especially for
> > > things like SMP=3Dn configs. For now, do the simplest thing: use the
> > > same implementation everywhere.
> > >
> > > Signed-off-by: Dave Hansen <[email protected]>
> > > Signed-off-by: Suren Baghdasaryan <[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=C3=B8nnev=C3=A5g <[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]
> > > ---
>
> <snip>
>
> > > -#endif /* CONFIG_PER_VMA_LOCK */
> >
> > Now that I'm looking closer into this, I think we would break NOMMU
> > case because nommu.c does not take VMA write locks at all. So,
> > lock_vma_under_rcu() for example would always succeed.
>
> I don't think anything's broken actually.
>
> Per-VMA locks was gated on CONFIG_MMU so nothing there assumes per-VMA fl=
ags,
> but now you have stuff that happens that didn't before but:
>
> * vm_area_free() -> vma_assert_detached() - fine - it's always detached i=
n nommu.
> * vm_area_dup() -> vma_lock_init() - no asserts, just sets refcount to 0 =
(correct).
>
> AFAICT nothing else.
>
> So seems fine to me?

One place that needs fixing is in BPF iterators. They use
lock_vma_under_rcu() which would always succeeds even if the VMA is
being modified. Instead of removing !IS_ENABLED(CONFIG_PER_VMA_LOCK)
check in bpf_iter_task_vma_new() I'll need to change it to
!IS_ENABLED(CONFIG_MMU).
I'll look into other parts and try to verify they do not affect NOMMU
but ultimately I would like to run some tests with this config, which
is not trivial...

>
> >
> > Extra per_VMA lock-related fields in the vm_area_struct and mm_struct
> > would also inflate NOMMU structure sizes without them being used. I'm
> > not sure if this is an issue we should consider.
>
> As nommu co-maintainer, no it's not :) I won't have that stuff blocking
> important changes for real arches.
>
> Go ahead! :)
>
> --
> Cheers, Lorenzo