From: Ard Biesheuvel <ardb@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Nicolas Pitre <nico@fluxnic.net>, Arnd Bergmann <arnd@arndb.de>,
Kees Cook <keescook@chromium.org>,
Keith Packard <keithpac@amazon.com>,
Linus Walleij <linus.walleij@linaro.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Tony Lindgren <tony@atomide.com>
Subject: [PATCH v4 5/7] ARM: switch_to: clean up Thumb2 code path
Date: Mon, 22 Nov 2021 10:28:14 +0100 [thread overview]
Message-ID: <20211122092816.2865873-6-ardb@kernel.org> (raw)
In-Reply-To: <20211122092816.2865873-1-ardb@kernel.org>
The load-multiple instruction that essentially performs the switch_to
operation in ARM mode, by loading all callee save registers as well the
stack pointer and the program counter, is split into 3 separate loads
for Thumb-2, with the IP register used as a temporary to capture the
value of R4 before it gets overwritten.
We can clean this up a bit, by sticking with a single LDMIA instruction,
but one that pops SP and PC into IP and LR, respectively, and by using
ordinary move register and branch instructions to get those values into
SP and PC. This also allows us to move the set_current call closer to
the assignment of SP, reducing the window where those are mutually out
of sync. This is especially relevant for CONFIG_VMAP_STACK, which is
being introduced in a subsequent patch, where we need to issue a load
that might fault from the new stack while running from the old one, to
ensure that stale PMD entries in the VMALLOC space are synced up.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Keith Packard <keithpac@amazon.com>
---
arch/arm/kernel/entry-armv.S | 23 +++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 1c7590eef712..ce8ca29461de 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -823,13 +823,26 @@ ENTRY(__switch_to)
#if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_SMP)
str r7, [r8]
#endif
- THUMB( mov ip, r4 )
mov r0, r5
+#if !defined(CONFIG_THUMB2_KERNEL)
set_current r7
- ARM( ldmia r4, {r4 - sl, fp, sp, pc} ) @ Load all regs saved previously
- THUMB( ldmia ip!, {r4 - sl, fp} ) @ Load all regs saved previously
- THUMB( ldr sp, [ip], #4 )
- THUMB( ldr pc, [ip] )
+ ldmia r4, {r4 - sl, fp, sp, pc} @ Load all regs saved previously
+#else
+ mov r1, r7
+ ldmia r4, {r4 - sl, fp, ip, lr} @ Load all regs saved previously
+
+ @ When CONFIG_THREAD_INFO_IN_TASK=n, the update of SP itself is what
+ @ effectuates the task switch, as that is what causes the observable
+ @ values of current and current_thread_info to change. When
+ @ CONFIG_THREAD_INFO_IN_TASK=y, setting current (and therefore
+ @ current_thread_info) is done explicitly, and the update of SP just
+ @ switches us to another stack, with few other side effects. In order
+ @ to prevent this distinction from causing any inconsistencies, let's
+ @ keep the 'set_current' call as close as we can to the update of SP.
+ set_current r1
+ mov sp, ip
+ ret lr
+#endif
UNWIND(.fnend )
ENDPROC(__switch_to)
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-22 9:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 9:28 [PATCH v4 0/7] ARM: add vmap'ed stack support Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 1/7] ARM: memcpy: use frame pointer as unwind anchor Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 2/7] ARM: memmove: " Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 3/7] ARM: memset: clean up unwind annotations Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 4/7] ARM: unwind: disregard unwind info before stack frame is set up Ard Biesheuvel
2021-11-22 9:28 ` Ard Biesheuvel [this message]
2021-11-22 9:28 ` [PATCH v4 6/7] ARM: entry: rework stack realignment code in svc_entry Ard Biesheuvel
2021-11-22 9:28 ` [PATCH v4 7/7] ARM: implement support for vmap'ed stacks Ard Biesheuvel
[not found] ` <CGME20211221103854eucas1p2592e38fcc84c1c3506fce87f1dab6739@eucas1p2.samsung.com>
2021-12-21 10:38 ` Marek Szyprowski
2021-12-21 10:42 ` Krzysztof Kozlowski
2021-12-21 10:46 ` Marek Szyprowski
2021-12-21 10:44 ` Ard Biesheuvel
2021-12-21 11:15 ` Marek Szyprowski
2021-12-21 13:34 ` Ard Biesheuvel
2021-12-21 13:51 ` Marek Szyprowski
2021-12-21 16:20 ` Ard Biesheuvel
2021-12-21 21:56 ` Marek Szyprowski
2021-12-23 14:23 ` Ard Biesheuvel
2021-12-28 14:39 ` Geert Uytterhoeven
2021-12-28 16:12 ` Geert Uytterhoeven
2021-12-28 16:27 ` Ard Biesheuvel
2022-01-05 11:08 ` Jon Hunter
2022-01-05 11:12 ` Ard Biesheuvel
2022-01-05 11:33 ` Jon Hunter
2022-01-05 13:53 ` Russell King (Oracle)
2022-01-05 16:49 ` Jon Hunter
2022-01-05 17:02 ` Ard Biesheuvel
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=20211122092816.2865873-6-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=keescook@chromium.org \
--cc=keithpac@amazon.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=ndesaulniers@google.com \
--cc=nico@fluxnic.net \
--cc=tony@atomide.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).