[PATCH 0/6] mm: Make per-VMA locks available in all builds

[Dave Hansen]

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@xxxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Cc: "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx>
Cc: Lorenzo Stoakes <ljs@xxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxxxxx>
Cc: Shakeel Butt <shakeel.butt@xxxxxxxxx>
Cc: linux-mm@xxxxxxxxx

 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(-)