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

On Mon, Aug 3, 2026 at 10:41=E2=80=AFAM Suren Baghdasaryan <[email protected]=
om> wrote:
>
> On Mon, Aug 3, 2026 at 9:08=E2=80=AFAM Lorenzo Stoakes (ARM) <ljs@kernel.=
org> 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@goo=
gle.com> wrote:
> > > >
> > > > From: Dave Hansen <[email protected]>
> > > >
> > > > The per-VMA locks have been around for several years. They've had s=
ome
> > > > 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_LO=
CK
> > > > 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 availabili=
ty
> > > > is letting per-VMA locks be used in SMP=3Dn configs. This lets us u=
se
> > > > 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 th=
e
> > > > 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 =
flags,
> > but now you have stuff that happens that didn't before but:
> >
> > * vm_area_free() -> vma_assert_detached() - fine - it's always detached=
 in 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! :)

Thanks for confirmation!

> >
> > --
> > Cheers, Lorenzo