Re: [RFC PATCH v1 1/2] x86/mm: use VMA lock for kernel faults on user addresses
From: Bo Zhang
Date: Tue Oct 27 2026 - 22:43:03 EST
On Sun, 2 Aug 2026 15:40:17 +0800 "Barry Song (Xiaomi)" <baohua@xxxxxxxxxx> wrote:
> Use the VMA lock for kernel faults on user addresses. This also
> makes the existing code below meaningful:
>
> /* Quick path to respond to signals */
> if (fault_signal_pending(fault, regs)) {
> if (!user_mode(regs))
> kernelmode_fixup_or_oops(regs, error_code, address,
> SIGBUS, BUS_ADRERR,
> ARCH_DEFAULT_PKEY);
> return;
> }
>
> Right now, the code above is dead because !user_mode always
> takes the mmap_lock path.
> ---
> - if (!(flags & FAULT_FLAG_USER))
> - goto lock_mmap;
> -
> vma = lock_vma_under_rcu(mm, address);
> if (!vma)
> goto lock_mmap;
I ran some numbers on x86 to quantify this. Using perf I counted how
often kernel faults on user addresses still fall back to the mmap_lock
slow path (lock_mm_and_find_vma), and the total time spent there,
before and after this patch.
Test setup: x86 host, booted with mem=4G.
Workload: vm-scalability case-mmap-pread-rand-mt, a multithreaded
random mmap+pread workload.
Fallback to the mmap_lock slow path (lock_mm_and_find_vma):
metric before_cnt before_ms after_cnt after_ms d_cnt% d_ms%
fault path 416 3510.000 5 256.780 -98.8% -92.7%
The number of kernel faults on user addresses that fall back to the
mmap_lock path drops by ~98%, and the time spent on that path drops
accordingly. So these faults are now handled under the per-VMA lock
as intended, and the corresponding mmap_lock contention goes away.
Thanks,
Bo