Re: [Ftrace][Bug] Failed on adding breakpoints, when used withkgdboc

[Steven Rostedt]

On Mon, 10 Feb 2014 22:59:24 +0530
yogesh tillu <tillu.yogesh@xxxxxxxxx> wrote:

> Hi Steve,
>      Thanks for the reply.
> Can we follow the approach of using api ftrace_set_notrace_ip (like
> ftrace_set_filter_ip ), and register ip for the notrace hash list from
> kgdb x86 arch code at the time of adding/removing breakpoint.
> 
> 

I'm not sure that will work. I have no problem skipping ftrace tests if
kgdb is enabled on boot up. That's just self test debugging anyway, and
pretty much useless for most people but those developing ftrace.

The reason I say it wont work, is that the filters are not global. That
is, you can call those "don't trace this function" API, and it will
only work for the ftrace function tracer. There's other users of ftrace
(perf, kprobes, stack-tracer, etc) that will still trace whatever it
wanted to trace.

As the bug only happens when function tracing is being enabled or
disabled when the kgdb breakpoint exists, I don't think this is
that much of a problem. I'm sure you could cause it to fail again, but
this always requires root privilege, for both ftrace and kgdb, and the
worse thing that happens is you get that splat and the function tracer
is disabled. It wont crash the kernel or do any other harm.

By skipping the start up tests, it is highly unlikely kgdb will trip up
function tracing unless you still have those break points around.

Now, if kgdb always keeps a breakpoint at do_page_fault() handler, then
perhaps we can do one of two things. The one, is like you said, don't
do function tracing on that function (skip it if kgdb is enabled).

The other is to be more like kprobes, and have kgdb hook into the
ftrace infrastructure. That is, if you find that you are about to add a
breakpoint to the start of a function, and that address happens to have
an ftrace _fentry_ call to it (or nop). Then just register your own
ftrace handler with the "REGS" flag, and the call back will act just
like a breakpoint, but only faster :-)

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/