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: 9+ 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-03 15:18 ` Lorenzo Stoakes (ARM)
2026-08-03 15:47 ` Suren Baghdasaryan
2026-08-03 22:37 ` Barry Song
2026-08-04 14:46 ` Lorenzo Stoakes (ARM)
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)
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.