Linux makes per-VMA locks unconditional across all configs

Dave Hansen and Suren Baghdasaryan have posted a series to the Linux kernel list that makes per-VMA locks available in every configuration, removing the architecture and Kconfig gates that had limited them for years.

Per-VMA locks let code lock a single virtual memory area instead of taking the process-wide mmap_lock. That cuts contention and avoids recursive locking trouble when work under mmap_lock can fault. Until now the feature was enabled only on selected architectures with SMP and an MMU, which blocked its use in generic paths and forced fallbacks everywhere else. The underlying pieces (RCU, maple trees, refcounts) already work without SMP or an MMU, so the series simply turns the locks on everywhere.

The tradeoff is a few extra fields on VMA and mm structures, including on !SMP and !MMU builds. NOMMU is handled by keeping VMAs effectively detached so read-locks fail and callers use mmap_lock, matching the fact that those systems do not write-lock VMAs.

Universal availability lets the series clean up Android binder reclaim and TCP zerocopy. Both had been trying a per-VMA lock and then falling back to mmap_lock; the fallback added complexity and often failed for the same reason the first attempt did (a writer holding mmap_lock). A new helper looks up an address and read-locks the VMA without the caller holding mmap_lock, waiting for writers only on the slow path so users need no fallback and never hold mmap_lock across faults. Hansen describes the result as both faster and simpler when applied correctly.

Matthew Wilcox questioned whether the helper’s documentation matches its deadlock properties if used while mmap_lock is already held for read, and asked for tighter commit messages. Baghdasaryan is carrying the series after Hansen’s earlier revisions.