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

"Lorenzo Stoakes (ARM)" <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.ports.arm.kernel
Message-ID <anCxz6JqVtebHxg7@lucifer>
On Sun, Aug 02, 2026 at 04:49:04PM +0800, Barry Song wrote:
> On Sun, Aug 2, 2026 at 3:40 PM Barry Song (Xiaomi) <[email protected]> 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))
> >                 goto no_context;
> >         return 0;
> > }
> >
> > Right now, the code above is dead because !user_mode always
> > takes the mmap_lock path.
> >
> > Co-developed-by: Bo Zhang <[email protected]>
> > Signed-off-by: Bo Zhang <[email protected]>
> > Signed-off-by: Barry Song (Xiaomi) <[email protected]>
> > ---
> >  arch/arm64/mm/fault.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index 85e23388f9bb..241f1ab07ab3 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -607,6 +607,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> >         unsigned int mm_flags = FAULT_FLAG_DEFAULT;
> >         unsigned long addr = untagged_addr(far);
> >         struct vm_area_struct *vma;
> > +       bool uaccess = false;
> >         int si_code;
> >         int pkey = -1;
> >
> > @@ -663,6 +664,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
> >                 if (!insn_may_access_user(regs->pc, esr))
> >                         die_kernel_fault("access to user memory outside uaccess routines",
> >                                          addr, esr, regs);
> > +               uaccess = true;
>
> https://sashiko.dev/#/patchset/20260802074018.73887-1-baohua%40kernel.org
>
> "Does this conditional bypass translation faults? Because this block is
> guarded by:
> if (is_ttbr0_addr(addr) && is_el1_permission_fault(addr, esr, regs)) {
> it appears uaccess is only set for permission faults like CoW or PAN
> violations.
> If a kernel uaccess routine accesses an unmapped user address, a translation
> fault occurs, making is_el1_permission_fault() evaluate to false.
> Would this cause demand paging in uaccess routines to fall back to the slow
> lock_mmap path, missing the intended optimization?"
>
> Good catch! I should have only modified a single line. Then
> unmapped PTEs would also benefit from the VMA lock:
>
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 85e23388f9bb..e1b406d667aa 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -674,7 +674,7 @@ static int __kprobes do_page_fault(unsigned long
> far, unsigned long esr,
>
>         perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, addr);
>
> -       if (!(mm_flags & FAULT_FLAG_USER))
> +       if (!(mm_flags & FAULT_FLAG_USER) && !is_ttbr0_addr(addr))
>                 goto lock_mmap;

I mean honestly it feels like, with the permanent VMA flags change, that maybe
this really needs to wait for Matthew's series?

There's duplication here too of course :)

But it begs the question of every other arch that does VMA page faulting.

So feels better suited as part of that change I think?

Maybe Matthew has thoughts.

>
>         vma = lock_vma_under_rcu(mm, addr);

--
Cheers, Lorenzo
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.