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

[Suren Baghdasaryan]

On Thu, Sep 10, 2026 at 3:09 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 8/31/26 22:30, Suren Baghdasaryan wrote:
> > From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
> >
> > The per-VMA locks have been around for several years. They've had some
> > 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=n 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=n configs. For now, do the simplest thing: use the
> > same implementation everywhere.
> >
> > == Considerations for NOMMU config ==
>
> Echoing what I commented on v6 after v7 was already sent (not realizing there
> was a v7 after my inbox got flooded)
>
> Maybe the NOMMU "support" could have been had in a separate prep patch (where a
> lot of the description below could have been moved), making the patch itself
> just mostly a removal of code.

Yeah, that would make reviewing indeed easier. I guess current
structure is the result of me adding NOMMU pieces to the pre-existing
patchset. I don't think it's worth refactoring but I can do that if
you insist.

>
>
> Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

Thanks!

>
> --
> Cheers,
>
> David