All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: andre.przywara@arm.com, ardb@kernel.org, catalin.marinas@arm.com,
	james.morse@arm.com, joey.gouly@arm.com, mark.rutland@arm.com,
	suzuki.poulose@arm.com, will@kernel.org
Subject: [PATCH 1/4] arm64: alternative: wait for other CPUs before patching
Date: Fri,  3 Dec 2021 10:47:20 +0000	[thread overview]
Message-ID: <20211203104723.3412383-2-mark.rutland@arm.com> (raw)
In-Reply-To: <20211203104723.3412383-1-mark.rutland@arm.com>

In __apply_alternatives_multi_stop() we have a "really simple polling
protocol" to avoid patching code that is concurrently executed on other
CPUs. Secondary CPUs wait for the boot CPU to signal that patching is
complete, but the boot CPU doesn't wait for secondaries to enter the
polling loop, and it's possible that patching starts while secondaries
are still within the stop_machine logic.

Let's fix this by adding a vaguely simple polling protocol where the
boot CPU waits for secondaries to signal that they have entered the
unpatchable stop function. We can use the arch_atomic_*() functions for
this, as they are not patched with alternatives.

At the same time, let's make `all_alternatives_applied` local to
__apply_alternatives_multi_stop(), since it is only used there, and this
makes the code a little clearer.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/alternative.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 3fb79b76e9d9..4f32d4425aac 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -21,9 +21,6 @@
 #define ALT_ORIG_PTR(a)		__ALT_PTR(a, orig_offset)
 #define ALT_REPL_PTR(a)		__ALT_PTR(a, alt_offset)
 
-/* Volatile, as we may be patching the guts of READ_ONCE() */
-static volatile int all_alternatives_applied;
-
 static DECLARE_BITMAP(applied_alternatives, ARM64_NCAPS);
 
 struct alt_region {
@@ -193,11 +190,17 @@ static void __nocfi __apply_alternatives(struct alt_region *region, bool is_modu
 }
 
 /*
- * We might be patching the stop_machine state machine, so implement a
- * really simple polling protocol here.
+ * Apply alternatives, ensuring that no CPUs are concurrently executing code
+ * being patched.
+ *
+ * We might be patching the stop_machine state machine or READ_ONCE(), so
+ * we implement a simple polling protocol.
  */
 static int __apply_alternatives_multi_stop(void *unused)
 {
+	/* Volatile, as we may be patching the guts of READ_ONCE() */
+	static volatile int all_alternatives_applied;
+	static atomic_t stopped_cpus = ATOMIC_INIT(0);
 	struct alt_region region = {
 		.begin	= (struct alt_instr *)__alt_instructions,
 		.end	= (struct alt_instr *)__alt_instructions_end,
@@ -205,12 +208,16 @@ static int __apply_alternatives_multi_stop(void *unused)
 
 	/* We always have a CPU 0 at this point (__init) */
 	if (smp_processor_id()) {
+		arch_atomic_inc(&stopped_cpus);
 		while (!all_alternatives_applied)
 			cpu_relax();
 		isb();
 	} else {
 		DECLARE_BITMAP(remaining_capabilities, ARM64_NPATCHABLE);
 
+		while (arch_atomic_read(&stopped_cpus) != num_online_cpus() - 1)
+			cpu_relax();
+
 		bitmap_complement(remaining_capabilities, boot_capabilities,
 				  ARM64_NPATCHABLE);
 
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-12-03 10:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 10:47 [PATCH 0/4] arm64: ensure CPUs are quiescent before patching Mark Rutland
2021-12-03 10:47 ` Mark Rutland [this message]
2021-12-10 14:49   ` [PATCH 1/4] arm64: alternative: wait for other CPUs " Catalin Marinas
2021-12-13 13:01     ` Mark Rutland
2021-12-13 13:27       ` Will Deacon
2021-12-13 13:31   ` Will Deacon
2021-12-13 13:41     ` Will Deacon
2021-12-13 13:54       ` Mark Rutland
2021-12-14 16:01         ` Will Deacon
2021-12-13 13:49     ` Mark Rutland
2021-12-03 10:47 ` [PATCH 2/4] arm64: insn: " Mark Rutland
2021-12-03 10:47 ` [PATCH 3/4] arm64: patching: unify stop_machine() patch synchronization Mark Rutland
2021-12-03 10:47 ` [PATCH 4/4] arm64: patching: mask exceptions in patch_machine() Mark Rutland

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=20211203104723.3412383-2-mark.rutland@arm.com \
    --to=mark.rutland@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@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 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.