public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/6] mm: Make per-VMA locks available in all builds
@ 2026-04-29 18:19 Dave Hansen
  2026-04-29 18:19 ` [PATCH 1/6] mm: Make per-VMA locks available universally Dave Hansen
                   ` (8 more replies)
  0 siblings, 9 replies; 16+ messages in thread
From: Dave Hansen @ 2026-04-29 18:19 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dave Hansen, Andrew Morton, Liam R. Howlett, linux-mm,
	Lorenzo Stoakes, Shakeel Butt, Suren Baghdasaryan,
	Vlastimil Babka

tl;dr: I hope I'm not missing something big here. The basic
observastion here is that forcing code to account for per-VMA lock
failure adds a lot of complexity. This series theorizes that with a
some Kconfig changes and a new helper, many callers can avoid writing
code that falls back to mmap_lock.

--

When working on some x86 shadow stack code, it was a real pain to
avoid causing recursive locking problems with mmap_lock. One way
to avoid those was to avoid mmap_lock and use per-VMA locks instead.
They are great, but they are not available in all configs which
makes them unusable in generic code, or if you want to completely
avoid mmap_lock.

Make per-VMA locks available in all configs. Right now, they are
only available on select architectures when SMP and MMU are enabled.
But all of the primitives that per-VMA locks are built on (RCU, maple
trees, refcounts) work just fine without SMP or MMU.

Their only real downside is that they make VMAs a wee bit bigger
on !MMU and !SMP builds.

The upside is much cleaner code, lower complexity and less #ifdeffery.

Building on top of universally-available per-VMA locks, introduce a
new helper. Since the new API does not require callers to have a
fallback to mmap_lock, it's much easier to use. Callers could
potentially replace this very common kernel idiom:

	mmap_read_lock(mm);
	vma = vma_lookup()
	// fiddle with vma
	mmap_read_unlock(mm);

with:

	vma = lock_vma_under_rcu_wait(mm, address);
	// fiddle with vma
	vma_end_read(vma);

Which avoids mmap_lock entirely in the fast path.

Things I think needs more discussion:
 * The new helper has a horrible name. Suggestions are very welcome.
 * I'm not very confident that this approach completely avoids the
   deadlock issues that arise from touching userspace while holding
   mm-related locks.
 * Can the helper avoid the goto, maybe by taking the VMA refcount
   while holding mmap_lock?
 * mm_struct and vm_area_struct "bloat"

I've included a couple patches where I think the new helper really
makes the code nicer.

I'm keeping the cc list on the short side for now because I'm not
actually proposing that we go ahead and do the ipv4 changes, for
example.

Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: linux-mm@kvack.org

 arch/arm/Kconfig                       |    1 
 arch/arm64/Kconfig                     |    1 
 arch/loongarch/Kconfig                 |    1 
 arch/powerpc/platforms/powernv/Kconfig |    1 
 arch/powerpc/platforms/pseries/Kconfig |    1 
 arch/riscv/Kconfig                     |    1 
 arch/s390/Kconfig                      |    1 
 arch/x86/Kconfig                       |    2 -
 arch/x86/kernel/shstk.c                |   47 +++++++++++-------------------
 drivers/android/binder_alloc.c         |   39 ++++++-------------------
 fs/proc/internal.h                     |    2 -
 fs/proc/task_mmu.c                     |   51 ---------------------------------
 include/linux/mm.h                     |   12 -------
 include/linux/mm_types.h               |    7 ----
 include/linux/mmap_lock.h              |   50 +-------------------------------
 kernel/fork.c                          |    2 -
 mm/Kconfig                             |   13 --------
 mm/mmap_lock.c                         |   45 +++++++++++++++++++++++++++--
 net/ipv4/tcp.c                         |   31 +++++---------------
 19 files changed, 82 insertions(+), 226 deletions(-)

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2026-05-05 16:39 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-29 18:19 [PATCH 0/6] mm: Make per-VMA locks available in all builds Dave Hansen
2026-04-29 18:19 ` [PATCH 1/6] mm: Make per-VMA locks available universally Dave Hansen
2026-04-29 18:19 ` [PATCH 2/6] binder: Make shrinker rely solely on per-VMA lock Dave Hansen
2026-04-29 18:19 ` [PATCH 3/6] mm: Add RCU-based VMA lookup that waits for writers Dave Hansen
2026-04-29 18:20 ` [PATCH 4/6] binder: Remove mmap_lock fallback Dave Hansen
2026-04-29 18:20 ` [PATCH 5/6] tcp: Remove mmap_lock fallback path Dave Hansen
2026-04-29 18:20 ` [PATCH 6/6] x86/mm: Avoid mmap lock for shadow stack pop fast path Dave Hansen
2026-05-04 23:15   ` Edgecombe, Rick P
2026-05-05 16:39     ` Dave Hansen
2026-04-29 18:22 ` [PATCH 0/6] mm: Make per-VMA locks available in all builds Dave Hansen
2026-04-30  8:11   ` Lorenzo Stoakes
2026-04-30 17:17     ` Suren Baghdasaryan
2026-04-30 17:20       ` Dave Hansen
2026-04-30  7:55 ` [syzbot ci] " syzbot ci
2026-04-30 16:59   ` Dave Hansen
     [not found] ` <20260430072053.e0be1b431bcff02831f07e9d@linux-foundation.org>
2026-04-30 16:52   ` [PATCH 0/6] " Dave Hansen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox