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

"Vlastimil Babka (SUSE)" <[email protected]>
Newsgroups gmane.linux.network,gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <[email protected]>
On 8/6/26 22:05, Suren Baghdasaryan wrote:
> From: Dave Hansen <[email protected]>
> 
> 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.
> 
> == Considerations for NOMMU config ==
> 
> NOMMU systems do not write-lock VMAs, therefore read-locking a VMA
> would always succeed unless VMA is detached. Therefore for NOMMU
> config we make vma_mark_attached() a NOOP, which keeps VMAs always in
> detached state. This causes VMA read-locking to always fail and the
> caller falls back to locking mmap_lock.
> 
> The following functions will have a different implementation in NOMMU
> config:
> 
> - vma_mark_attached(), vma_mark_detached() are made NOOPs, keeping VMAs
> always in a detached state and preventing assertions and refcount
> underflows;
> 
> - vma_start_write(), vma_start_write_killable() are made NOOPs to avoid
> warnings in __vma_start_write() due to VMAs being detached.
> These functions are not used in NOMMU code but __vma_start_write()
> is an exported function, therefore might be used by drivers.
> 
> - vma_assert_attached() is made NOOP because it's reachable from NOMMU
> code via split_vma()->vma_iter_store_new()->vma_iter_store_overwrite();
> 
> - vma_assert_write_locked() is asserting vma->vm_mm is write-locked;
> 
> The following functions work for both MMU and NOMMU configs:
> 
> - vma_lock_init() performs the same initialization as for MMU config;
> 
> - mm_lock_seqcount_init(), mm_lock_seqcount_begin(), mm_lock_seqcount_end()
> are called from mmap_write_{lock|unlock} and update mm_lock_seq correctly.
> 
> - mmap_lock_speculate_try_begin(), mmap_lock_speculate_retry() work as is
> because mm_lock_seq is updated correctly;
> 
> - vma_start_read(), vma_start_read_locked() will always fail because VMAs
> are always detached;
> 
> - vma_end_read() will never be called because vma_start_read() never
> succeeds;
> 
> - vma_is_attached() always return false because VMAs are always detached;
> 
> - vma_assert_detached() will never trigger because VMAs are never attached;
> 
> Changes in the following files are not affecting NOMMU config:
> 
> task_mmu.c - not compiled when CONFIG_MMU=n;
> pagewalk.c - not compiled when CONFIG_MMU=n;
> userfaultfd.c - not compiled when CONFIG_MMU=n (CONFIG_USERFAULTFD depends
> on CONFIG_MMU);
> 
> The following changes are made to keep NOMMU config working like before:
> 
> stack_map_lock_vma() - keeps mmap_lock in NOMMU config;
> bpf_iter_task_vma_new() - bails out in NOMMU config;
> 
> Signed-off-by: Dave Hansen <[email protected]>
> Signed-off-by: Suren Baghdasaryan <[email protected]>
> Cc: Suren Baghdasaryan <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: "Liam R. Howlett" <[email protected]>
> Cc: Lorenzo Stoakes <[email protected]>
> Cc: Vlastimil Babka <[email protected]>
> Cc: Shakeel Butt <[email protected]>
> Cc: [email protected]
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Arve Hjønnevåg <[email protected]>
> Cc: Todd Kjos <[email protected]>
> Cc: Christian Brauner <[email protected]>
> Cc: Carlos Llamas <[email protected]>
> Cc: Alice Ryhl <[email protected]>
> Cc: "David S. Miller" <[email protected]>
> Cc: David Ahern <[email protected]>
> Cc: [email protected]

Acked-by: Vlastimil Babka (SUSE) <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.