Re: [RFC PATCH v1 1/2] x86/mm: use VMA lock for kernel faults on user addresses

[Bo Zhang <zhangbo0325@gmail.com>]

On Sun, 2 Aug 2026 15:40:17 +0800 "Barry Song (Xiaomi)" <baohua@kernel.org> 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