[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <tip-34bfab0eaf0fb5c6fb14c6b4013b06cdc7984466@git.kernel.org>
Date: Tue, 20 Dec 2016 01:35:08 -0800
From: tip-bot for Borislav Petkov <tipbot@...or.com>
To: linux-tip-commits@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, hpa@...or.com,
torvalds@...ux-foundation.org, peterz@...radead.org,
tglx@...utronix.de, bp@...e.de, luto@...capital.net,
gnomes@...rguk.ukuu.org.uk, luto@...nel.org, hmh@....eng.br,
brgerst@...il.com, mingo@...nel.org, tedheadster@...il.com,
andrew.cooper3@...rix.com
Subject: [tip:x86/urgent] x86/alternatives: Do not use sync_core() to
serialize I$
Commit-ID: 34bfab0eaf0fb5c6fb14c6b4013b06cdc7984466
Gitweb: http://git.kernel.org/tip/34bfab0eaf0fb5c6fb14c6b4013b06cdc7984466
Author: Borislav Petkov <bp@...e.de>
AuthorDate: Sat, 3 Dec 2016 16:02:58 +0100
Committer: Ingo Molnar <mingo@...nel.org>
CommitDate: Tue, 20 Dec 2016 09:36:42 +0100
x86/alternatives: Do not use sync_core() to serialize I$
We use sync_core() in the alternatives code to stop speculative
execution of prefetched instructions because we are potentially changing
them and don't want to execute stale bytes.
What it does on most machines is call CPUID which is a serializing
instruction. And that's expensive.
However, the instruction cache is serialized when we're on the local CPU
and are changing the data through the same virtual address. So then, we
don't need the serializing CPUID but a simple control flow change. Last
being accomplished with a CALL/RET which the noinline causes.
Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Borislav Petkov <bp@...e.de>
Reviewed-by: Andy Lutomirski <luto@...nel.org>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: Andy Lutomirski <luto@...capital.net>
Cc: Brian Gerst <brgerst@...il.com>
Cc: Henrique de Moraes Holschuh <hmh@....eng.br>
Cc: Matthew Whitehead <tedheadster@...il.com>
Cc: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Link: http://lkml.kernel.org/r/20161203150258.vwr5zzco7ctgc4pe@pd.tnic
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
arch/x86/kernel/alternative.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 5cb272a..c5b8f76 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -337,7 +337,11 @@ done:
n_dspl, (unsigned long)orig_insn + n_dspl + repl_len);
}
-static void __init_or_module optimize_nops(struct alt_instr *a, u8 *instr)
+/*
+ * "noinline" to cause control flow change and thus invalidate I$ and
+ * cause refetch after modification.
+ */
+static void __init_or_module noinline optimize_nops(struct alt_instr *a, u8 *instr)
{
unsigned long flags;
@@ -346,7 +350,6 @@ static void __init_or_module optimize_nops(struct alt_instr *a, u8 *instr)
local_irq_save(flags);
add_nops(instr + (a->instrlen - a->padlen), a->padlen);
- sync_core();
local_irq_restore(flags);
DUMP_BYTES(instr, a->instrlen, "%p: [%d:%d) optimized NOPs: ",
@@ -359,9 +362,12 @@ static void __init_or_module optimize_nops(struct alt_instr *a, u8 *instr)
* This implies that asymmetric systems where APs have less capabilities than
* the boot processor are not handled. Tough. Make sure you disable such
* features by hand.
+ *
+ * Marked "noinline" to cause control flow change and thus insn cache
+ * to refetch changed I$ lines.
*/
-void __init_or_module apply_alternatives(struct alt_instr *start,
- struct alt_instr *end)
+void __init_or_module noinline apply_alternatives(struct alt_instr *start,
+ struct alt_instr *end)
{
struct alt_instr *a;
u8 *instr, *replacement;
@@ -667,7 +673,6 @@ void *__init_or_module text_poke_early(void *addr, const void *opcode,
unsigned long flags;
local_irq_save(flags);
memcpy(addr, opcode, len);
- sync_core();
local_irq_restore(flags);
/* Could also do a CLFLUSH here to speed up CPU recovery; but
that causes hangs on some VIA CPUs. */
Powered by blists - more mailing lists