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

On Mon, Aug 3, 2026 at 10:41 AM Suren Baghdasaryan [off-list ref] wrote:

On Mon, Aug 3, 2026 at 9:08 AM Lorenzo Stoakes (ARM) [off-list ref] wrote:

quoted

On Mon, Aug 03, 2026 at 08:24:44AM -0700, Suren Baghdasaryan wrote:

quoted

On Sun, Aug 2, 2026 at 2:55 PM Suren Baghdasaryan [off-list ref] wrote:

quoted

From: Dave Hansen <dave.hansen@linux.intel.com>

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.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R. Howlett" <redacted>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: linux-mm@kvack.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Carlos Llamas <cmllamas@google.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: netdev@vger.kernel.org
---

<snip>

quoted

quoted

-#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...

quoted

quoted

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!

quoted

--
Cheers, Lorenzo