lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 16 May 2020 01:45:51 +0200 From: Thomas Gleixner <tglx@...utronix.de> To: LKML <linux-kernel@...r.kernel.org> Cc: x86@...nel.org, "Paul E. McKenney" <paulmck@...nel.org>, Andy Lutomirski <luto@...nel.org>, Alexandre Chartre <alexandre.chartre@...cle.com>, Frederic Weisbecker <frederic@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Sean Christopherson <sean.j.christopherson@...el.com>, Masami Hiramatsu <mhiramat@...nel.org>, Petr Mladek <pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>, Joel Fernandes <joel@...lfernandes.org>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, Juergen Gross <jgross@...e.com>, Brian Gerst <brgerst@...il.com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Will Deacon <will@...nel.org>, Tom Lendacky <thomas.lendacky@....com>, Wei Liu <wei.liu@...nel.org>, Michael Kelley <mikelley@...rosoft.com>, Jason Chen CJ <jason.cj.chen@...el.com>, Zhao Yakui <yakui.zhao@...el.com>, "Peter Zijlstra (Intel)" <peterz@...radead.org> Subject: [patch V6 04/37] x86: Make hardware latency tracing explicit The hardware latency tracer calls into trace_sched_clock and ends up in various instrumentable functions which is problemeatic vs. the kprobe handling especially the text poke machinery. It's invoked from nmi_enter/exit(), i.e. non-instrumentable code. Use nmi_enter/exit_notrace() instead. These variants do not invoke the hardware latency tracer which avoids chasing down complex callchains to make them non-instrumentable. The real interesting measurement is the actual NMI handler. Add an explicit invocation for the hardware latency tracer to it. #DB and #BP are uninteresting as they really should not be in use when analzying hardware induced latencies. If #DF hits, hardware latency is definitely not interesting anymore and in case of a machine check the hardware latency is not the most troublesome issue either. Signed-off-by: Thomas Gleixner <tglx@...utronix.de> --- arch/x86/kernel/cpu/mce/core.c | 4 ++-- arch/x86/kernel/nmi.c | 6 ++++-- arch/x86/kernel/traps.c | 12 +++++++----- 3 files changed, 13 insertions(+), 9 deletions(-) --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -1916,7 +1916,7 @@ static __always_inline void exc_machine_ mce_check_crashing_cpu()) return; - nmi_enter(); + nmi_enter_notrace(); /* * The call targets are marked noinstr, but objtool can't figure * that out because it's an indirect call. Annotate it. @@ -1924,7 +1924,7 @@ static __always_inline void exc_machine_ instrumentation_begin(); machine_check_vector(regs); instrumentation_end(); - nmi_exit(); + nmi_exit_notrace(); } static __always_inline void exc_machine_check_user(struct pt_regs *regs) --- a/arch/x86/kernel/nmi.c +++ b/arch/x86/kernel/nmi.c @@ -334,6 +334,7 @@ static noinstr void default_do_nmi(struc __this_cpu_write(last_nmi_rip, regs->ip); instrumentation_begin(); + ftrace_nmi_handler_enter(); handled = nmi_handle(NMI_LOCAL, regs); __this_cpu_add(nmi_stats.normal, handled); @@ -420,6 +421,7 @@ static noinstr void default_do_nmi(struc unknown_nmi_error(reason, regs); out: + ftrace_nmi_handler_exit(); instrumentation_end(); } @@ -536,14 +538,14 @@ DEFINE_IDTENTRY_NMI(exc_nmi) } #endif - nmi_enter(); + nmi_enter_notrace(); inc_irq_stat(__nmi_count); if (!ignore_nmis) default_do_nmi(regs); - nmi_exit(); + nmi_exit_notrace(); #ifdef CONFIG_X86_64 if (unlikely(this_cpu_read(update_debug_stack))) { --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -387,7 +387,7 @@ DEFINE_IDTENTRY_DF(exc_double_fault) } #endif - nmi_enter(); + nmi_enter_notrace(); instrumentation_begin(); notify_die(DIE_TRAP, str, regs, error_code, X86_TRAP_DF, SIGSEGV); @@ -632,12 +632,14 @@ DEFINE_IDTENTRY_RAW(exc_int3) instrumentation_end(); idtentry_exit(regs); } else { - nmi_enter(); + nmi_enter_notrace(); instrumentation_begin(); + ftrace_nmi_handler_enter(); if (!do_int3(regs)) die("int3", regs, 0); + ftrace_nmi_handler_exit(); instrumentation_end(); - nmi_exit(); + nmi_exit_notrace(); } } @@ -849,7 +851,7 @@ static void noinstr handle_debug(struct static __always_inline void exc_debug_kernel(struct pt_regs *regs, unsigned long dr6) { - nmi_enter(); + nmi_enter_notrace(); /* * The SDM says "The processor clears the BTF flag when it * generates a debug exception." Clear TIF_BLOCKSTEP to keep @@ -871,7 +873,7 @@ static __always_inline void exc_debug_ke if (dr6) handle_debug(regs, dr6, false); - nmi_exit(); + nmi_exit_notrace(); } static __always_inline void exc_debug_user(struct pt_regs *regs,
Powered by blists - more mailing lists