The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Barry Song <baohua@kernel.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, x86@kernel.org,
	 linux-arm-kernel@lists.infradead.org, surenb@google.com,
	liam@infradead.org, vbabka@kernel.org,  shakeel.butt@linux.dev,
	david@kernel.org, linux-kernel@vger.kernel.org,
	 zhanghongru@xiaomi.com, willy@infradead.org,
	zhangbo56@xiaomi.com
Subject: Re: [RFC PATCH v1 2/2] arm64/mm: use VMA lock for kernel faults on user addresses
Date: Mon, 3 Aug 2026 16:32:27 +0100	[thread overview]
Message-ID: <anCxz6JqVtebHxg7@lucifer> (raw)
In-Reply-To: <CAGsJ_4wLG77Y5r9Dy6QOqgmjNM5W1E5aGqKyJb7Bp3WGemNFmg@mail.gmail.com>

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) <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))
> >                 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 <zhangbo56@xiaomi.com>
> > Signed-off-by: Bo Zhang <zhangbo56@xiaomi.com>
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > ---
> >  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

      reply	other threads:[~2026-08-03 15:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02  7:40 [RFC PATCH v1 0/2] mm: use VMA lock for kernel faults on user addresses Barry Song (Xiaomi)
2026-08-02  7:40 ` [RFC PATCH v1 1/2] x86/mm: " Barry Song (Xiaomi)
2026-08-03 15:18   ` Lorenzo Stoakes (ARM)
2026-08-03 15:47     ` Suren Baghdasaryan
2026-08-02  7:40 ` [RFC PATCH v1 2/2] arm64/mm: " Barry Song (Xiaomi)
2026-08-02  8:49   ` Barry Song
2026-08-03 15:32     ` Lorenzo Stoakes (ARM) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=anCxz6JqVtebHxg7@lucifer \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=david@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=zhangbo56@xiaomi.com \
    --cc=zhanghongru@xiaomi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox