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

From: David Hildenbrand (Arm)

Date: Mon Sep 07 2026 - 13:28:34 EST


On 8/13/26 21:34, 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 ==

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.


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

--
Cheers,

David