From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Anvin <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-arch <linux-arch@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 0/7] arm64 / x86-64: low-level code generation issues
Date: Mon, 10 Jun 2024 13:48:14 -0700 [thread overview]
Message-ID: <20240610204821.230388-1-torvalds@linux-foundation.org> (raw)
So this is the result of me doing some profiling on my 128-core Altra
box. I've sent out versions of this before, but they've all been fairly
ugly partial series.
This is the full cleaned-up series with patches split up to be logical,
and with fixes from some of the commentary from previous patches.
The first four patches are for the 'runtime constant' code, where I did
the initial implementation on x86-64 just because I was more comfy with
that, and the arm64 version of it came once I had the x86-64 side
working.
The horror that is __d_lookup_rcu() shows up a lot more on my Altra box
because of the relatively pitiful caches, but it's something that I've
wanted on x86-64 before. The arm64 numbers just made me bite the
bullet on the whole runtime constant thing.
The last three patches are purely arm64-specific, and just fix up some
nasty code generation in the user access functions. I just noticed that
I will need to implement 'user_access_save()' for KCSAN now that I do
the unsafe user access functions.
Anyway, that 'user_access_save/restore()' issue only shows up with
KCSAN. And it would be a no-op thanks to arm64 doing SMAP the right way
(pet peeve: arm64 did what I told the x86 designers to do originally,
but they claimed was too hard, so we ended up with that CLAC/STAC
instead)...
Sadly that "no-op for KCSAN" would is except for the horrid
CONFIG_ARM64_SW_TTBR0_PAN case, which is why I'm not touching it. I'm
hoping some hapless^Whelpful arm64 person is willing to tackle this (or
maybe make KCSAN and ARM64_SW_TTBR0_PAN incompatible in the Kconfig).
Note: the final access_ok() change in 7/7 is a API relaxation and
cleanup, and as such much more worrisome than the other patches. It's
_simpler_ than the other patches, but the others aren't intended to
really change behavior. That one does.
Linus Torvalds (7):
vfs: dcache: move hashlen_hash() from callers into d_hash()
add default dummy 'runtime constant' infrastructure
x86: add 'runtime constant' support
arm64: add 'runtime constant' support
arm64: start using 'asm goto' for get_user() when available
arm64: start using 'asm goto' for put_user() when available
arm64: access_ok() optimization
arch/arm64/include/asm/runtime-const.h | 75 ++++++++++
arch/arm64/include/asm/uaccess.h | 191 +++++++++++++++++--------
arch/arm64/kernel/mte.c | 12 +-
arch/arm64/kernel/vmlinux.lds.S | 3 +
arch/x86/include/asm/runtime-const.h | 61 ++++++++
arch/x86/kernel/vmlinux.lds.S | 3 +
fs/dcache.c | 17 ++-
include/asm-generic/Kbuild | 1 +
include/asm-generic/runtime-const.h | 15 ++
include/asm-generic/vmlinux.lds.h | 8 ++
10 files changed, 319 insertions(+), 67 deletions(-)
create mode 100644 arch/arm64/include/asm/runtime-const.h
create mode 100644 arch/x86/include/asm/runtime-const.h
create mode 100644 include/asm-generic/runtime-const.h
--
2.45.1.209.gc6f12300df
next reply other threads:[~2024-06-10 20:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-10 20:48 Linus Torvalds [this message]
2024-06-10 20:48 ` [PATCH 1/7] vfs: dcache: move hashlen_hash() from callers into d_hash() Linus Torvalds
2024-06-10 20:48 ` [PATCH 2/7] add default dummy 'runtime constant' infrastructure Linus Torvalds
2024-06-12 10:04 ` Borislav Petkov
2024-06-10 20:48 ` [PATCH 3/7] x86: add 'runtime constant' support Linus Torvalds
2024-06-10 20:48 ` [PATCH 4/7] arm64: " Linus Torvalds
2024-06-11 14:29 ` Mark Rutland
2024-06-11 16:56 ` Linus Torvalds
2024-06-11 17:20 ` [PATCH 4/7 v2] " Linus Torvalds
2024-06-12 18:42 ` Mark Rutland
2024-06-11 17:48 ` [PATCH 4/7] " Mark Rutland
2024-06-11 17:59 ` Linus Torvalds
2024-06-11 18:59 ` Linus Torvalds
2024-06-11 20:22 ` Mark Rutland
2024-06-11 21:08 ` Linus Torvalds
2024-06-10 20:48 ` [PATCH 5/7] arm64: start using 'asm goto' for get_user() when available Linus Torvalds
2024-06-10 20:48 ` [PATCH 6/7] arm64: start using 'asm goto' for put_user() " Linus Torvalds
2024-06-11 21:55 ` Nathan Chancellor
2024-06-11 23:29 ` Linus Torvalds
2024-06-11 23:40 ` [PATCH 6/7 v2] " Linus Torvalds
2024-06-10 20:48 ` [PATCH 7/7] arm64: access_ok() optimization Linus Torvalds
2024-06-12 18:41 ` [PATCH 0/7] arm64 / x86-64: low-level code generation issues Mark Rutland
2024-06-12 20:02 ` Linus Torvalds
2024-06-12 22:25 ` Linus Torvalds
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=20240610204821.230388-1-torvalds@linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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).