On Tue, Apr 22, 2025 at 3:54 PM Andrii Nakryiko <andrii.nakry...@gmail.com> wrote: > > On Fri, Apr 18, 2025 at 10:50 AM Suren Baghdasaryan <sur...@google.com> wrote: > > > > Utilize speculative vma lookup to find and snapshot a vma without > > taking mmap_lock during PROCMAP_QUERY ioctl execution. Concurrent > > address space modifications are detected and the lookup is retried. > > While we take the mmap_lock for reading during such contention, we > > do that momentarily only to record new mm_wr_seq counter. > > PROCMAP_QUERY is an even more obvious candidate for fully lockless > speculation, IMO (because it's more obvious that vma's use is > localized to do_procmap_query(), instead of being spread across > m_start/m_next and m_show as with seq_file approach). We do > rcu_read_lock(), mmap_lock_speculate_try_begin(), query for VMA (no > mmap_read_lock), use that VMA to produce (speculative) output, and > then validate that VMA or mm_struct didn't change with > mmap_lock_speculate_retry(). If it did - retry, if not - we are done. > No need for vma_copy and any gets/puts, no?
Yeah, since we can simply retry, this should indeed work without trying to stabilize the vma. I'll update the code to simplify this. Thanks! > > > This change is designed to reduce mmap_lock contention and prevent > > PROCMAP_QUERY ioctl calls (often a low priority task, such as > > monitoring/data collection services) from blocking address space > > updates. > > > > Signed-off-by: Suren Baghdasaryan <sur...@google.com> > > --- > > fs/proc/task_mmu.c | 63 ++++++++++++++++++++++++++++++++++++++++------ > > 1 file changed, 55 insertions(+), 8 deletions(-) > > > > [...]
