From: "Barry Song (Xiaomi)" <baohua@kernel.org>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: x86@kernel.org, linux-arm-kernel@lists.infradead.org,
surenb@google.com, liam@infradead.org, ljs@kernel.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,
"Barry Song (Xiaomi)" <baohua@kernel.org>
Subject: [RFC PATCH v1 0/2] mm: use VMA lock for kernel faults on user addresses
Date: Sun, 2 Aug 2026 15:40:16 +0800 [thread overview]
Message-ID: <20260802074018.73887-1-baohua@kernel.org> (raw)
Right now, kernel faults on user addresses, such as those from
copy_from_user() and copy_to_user(), unconditionally fall back
to the mmap_lock path.
This patchset switches them to the per-VMA lock path for three
reasons:
1. These faults are common. On a typical Ubuntu system, hundreds
of kernel faults on user addresses occur every second in
python3, apt-esm-hook, package-data-do, teamviewerd, bash,
scudo, cscope, gnome-shell, systemd, and many other
applications. Handling these faults under mmap_lock
unnecessarily increases lock contention.
2. It removes one obstacle to simplifying filemap_fault().
Matthew has proposed removing the page fault retry path and
performing I/O while holding locks [1]. Based on that
approach, Hongru has already reported regressions caused by
performing I/O under mmap_lock for kernel faults on user
addresses [2]. This patchset removes that obstacle.
Another source of I/O under mmap_lock is GUP, which also
relies on mmap_lock today and has been reported by Hongru to
exhibit similar regressions [2]. It appears Rik van Riel may
be addressing this separately [3].
3. The current implementation is inconsistent. Although kernel
faults on user addresses always fall back to mmap_lock,
arch/*/mm/fault.c still performs !user_mode checks in the
per-VMA lock path, making that code effectively dead.
As an RFC, this patchset demonstrates the approach on x86 and
arm64 only. Other architectures will need to be updated as well.
[1] https://lore.kernel.org/linux-mm/20260625195040.2508362-1-willy@infradead.org/
[2] https://lore.kernel.org/linux-mm/20260712132759.2030823-1-zhanghongru@xiaomi.com/
[3] https://lore.kernel.org/linux-mm/20260724222934.1463812-1-riel@surriel.com/
Barry Song (Xiaomi) (2):
x86/mm: use VMA lock for kernel faults on user addresses
arm64/mm: use VMA lock for kernel faults on user addresses
arch/arm64/mm/fault.c | 4 +++-
arch/x86/mm/fault.c | 3 ---
2 files changed, 3 insertions(+), 4 deletions(-)
--
2.39.3 (Apple Git-146)
next reply other threads:[~2026-08-02 7:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 7:40 Barry Song (Xiaomi) [this message]
2026-08-02 7:40 ` [RFC PATCH v1 1/2] x86/mm: use VMA lock for kernel faults on user addresses Barry Song (Xiaomi)
2026-08-02 7:40 ` [RFC PATCH v1 2/2] arm64/mm: " Barry Song (Xiaomi)
2026-08-02 8:49 ` Barry Song
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=20260802074018.73887-1-baohua@kernel.org \
--to=baohua@kernel.org \
--cc=akpm@linux-foundation.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=ljs@kernel.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;
as well as URLs for NNTP newsgroup(s).