[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20151106083721.1e94e47e@gandalf.local.home>
Date: Fri, 6 Nov 2015 08:37:21 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>
Subject: Re: What's TRACE_IRQS_OFF_DEBUG for?
On Thu, 5 Nov 2015 23:24:22 -0800
Andy Lutomirski <luto@...capital.net> wrote:
> The comment says:
>
> /*
> * When dynamic function tracer is enabled it will add a breakpoint
> * to all locations that it is about to modify, sync CPUs, update
> * all the code, sync CPUs, then remove the breakpoints. In this time
> * if lockdep is enabled, it might jump back into the debug handler
> * outside the updating of the IST protection. (TRACE_IRQS_ON/OFF).
> *
> * We need to change the IDT table before calling TRACE_IRQS_ON/OFF to
> * make sure the stack pointer does not get reset back to the top
> * of the debug stack, and instead just reuses the current stack.
> */
> #if defined(CONFIG_DYNAMIC_FTRACE) && defined(CONFIG_TRACE_IRQFLAGS)
>
> .macro TRACE_IRQS_OFF_DEBUG
> ...
>
> Unless I'm missing something, TRACE_IRQS_OFF isn't a tracepoint at
> all, though -- it's a lockdep debugging thing. Is the worry that
> someone might stick a kprobe or similar in the trace_hardirqs_off
> code? If so, could we just disable that instead?
>
> I could easily be missing something here.
>
It has nothing to do with kprobes or tracepoints. It's about function
tracing. When we enable function tracing, we add a break point to every
function that is being enabled to modify the mcount (or fentry)
location into the call to the function tracer. Same goes with
disabling function tracing (putting back the nop).
Lockdep itself doesn't get traced, but it can call functions that do.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists