On Fri, May 15, 2020 at 5:10 PM Thomas Gleixner <t...@linutronix.de> wrote:
>
>
> 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.
>
> @@ -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();
Why can't exc_debug_kernel() handle instrumentation? We shouldn't
recurse into #DB since we've already cleared DR7, right?
