From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Xie Yuanbin <xieyuanbin1@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org,
torvalds@linux-foundation.org, viro@zeniv.linux.org.uk,
will@kernel.org
Subject: [PATCH 0/3] ARM: fix hash_name() and branch predictor issues
Date: Mon, 8 Dec 2025 12:34:27 +0000 [thread overview]
Message-ID: <aTbF009476Iufory@shell.armlinux.org.uk> (raw)
This series, which I'm intending to be part of my upcoming pull request
for this merge window (note - will be sent before Thursday, otherwise
it won't be until maybe the middle of January) fixes the recently
reported hash_name() issue, and also the long standing branch predictor
hardening smp_processor_id() warning which occurs due to interrupts
being enabled.
Fixing this isn't trivial because there are many paths through
do_page_fault() which are non-obvious.
For example, we detect page faults by the kernel attempting to execute
memory that it shouldn't and print such a warning. If we introduce an
early address check, we avoid that detection, making it become a
plain kernel oops without the informative error message.
The first patch adds an additional check in __do_kernel_fault() to
detect this condition. This patch is a non-obvious dependency for the
next patch.
The second patch handles faults above the top of userspace entirely
separately, meaning we have a simpler and more obvious fault path,
which avoids any possibility of taking any MM mutexes, which is the
cause of the hash_name() problem.
The third patch moves harden_branch_predictor() out of
__do_user_fault() and to appropriate places in the parent functions.
The reason this has been avoided thus far is because do_page_fault()
can be a hot path (since it's used for page aging as well) but with
kernel address faults being handled by an entirely separate path,
this avoids adding to that overhead.
I would like to get some attributations for this - specifically
tested-by.
Thanks.
arch/arm/mm/alignment.c | 6 +++-
arch/arm/mm/fault.c | 74 +++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 67 insertions(+), 13 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next reply other threads:[~2025-12-08 12:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 12:34 Russell King (Oracle) [this message]
2025-12-08 12:34 ` [PATCH 1/3] ARM: allow __do_kernel_fault() to report execution of memory faults Russell King (Oracle)
2025-12-09 4:02 ` Xie Yuanbin
2025-12-09 8:43 ` Russell King (Oracle)
2025-12-08 12:34 ` [PATCH 2/3] ARM: fix hash_name() fault Russell King (Oracle)
2025-12-08 12:35 ` [PATCH 3/3] ARM: fix branch predictor hardening Russell King (Oracle)
2025-12-08 15:08 ` [PATCH 0/3] ARM: fix hash_name() and branch predictor issues Xie Yuanbin
2025-12-08 15:59 ` Russell King (Oracle)
2025-12-08 16:47 ` Russell King (Oracle)
2025-12-09 2:52 ` Xie Yuanbin
2025-12-09 8:56 ` Xie Yuanbin
2025-12-09 8:59 ` Russell King (Oracle)
2025-12-09 9:09 ` Xie Yuanbin
2025-12-10 9:08 ` Xie Yuanbin
2025-12-10 15:11 ` Russell King (Oracle)
2025-12-11 4:07 ` Xie Yuanbin
2025-12-09 2:15 ` Xie Yuanbin
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=aTbF009476Iufory@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=xieyuanbin1@huawei.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.