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
prev parent 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