Linux makes per-VMA locks unconditional across all configs

The Linux memory-management subsystem is set to make per-VMA locks available in every configuration, ending years of architecture- and Kconfig-gated support that forced fallbacks to the coarser mmap_lock.

Dave Hansen originally wrote the work; Suren Baghdasaryan has taken over the series and posted it on the kernel mailing list. Until now the locks existed only on selected architectures when SMP and an MMU were enabled. The primitives underneath them (RCU, maple trees, refcounts) already work without those constraints, so the conditional compilation mainly reflected expected benefit rather than true support. Making the locks universal removes that #ifdeffery and lets common code rely on them.

That change matters because mmap_lock is a frequent source of contention and recursive-locking headaches. Per-VMA locks let paths touch a single virtual memory area without holding the process-wide lock. With the locks always present, Hansen and Baghdasaryan add a helper that looks up and read-locks a VMA, waiting briefly for writers when needed instead of failing. Callers no longer need a separate mmap_lock fallback path; the fast path can avoid mmap_lock entirely.

Binder reclaim and TCP zero-copy receive are the first cleanups. Both previously tried a per-VMA lock, then fell back to mmap_read_trylock or a full mmap_read_lock when that failed. Those fallbacks added complexity and, in the binder shrinker case, often retried in vain when a writer already held mmap_lock. The new helper collapses the logic. NOMMU builds keep VMAs effectively detached so read-locking fails cleanly back to mmap_lock; binder and the TCP path are MMU-only anyway.

The cost is a few extra fields in core mm structures, including on !SMP and !MMU kernels where the locks buy less. Reviewers have acknowledged the direction; the payoff is simpler generic code and fewer special cases wherever VMA lifetime must be handled under concurrency.