On Tue, 13 Dec 2016 01:30:01 +0900
Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> Sorry to miss updating those tracers. I guess it's no more necessary once
> the patch 8 is applied so that functions in the notrace filter will not be
> recorded.
>
> Or maybe we need to change the prepare_ftrace_return() so that the
> graph_entry callback should be called after ftrace_push_return_trace() as
> some archs do.
I plan on updating fgraph in general so this should all be handled then.
>
> >
> > Have the print functions handle cases where a tracer still records functions
> > even when they are in set_graph_notrace.
>
> I think it'd be better (or consistent, at least) not printing negative index
> records rather than showing entry only.
I thought about this too, but I'm more concerned about it not crashing
the kernel than to show a proper trace. The fix will just make sure it
doesn't crash.
>
> >
> > Also add warnings if the depth is below zero before accessing the array.
> >
> > Note, the function graph logic will still prevent the return of these
> > functions from being recorded, which means that they will be left hanging
> > without a return. For example:
> >
> > # echo '*spin*' > set_graph_notrace
> > # echo 1 > options/display-graph
> > # echo wakeup > current_tracer
> > # cat trace
> > [...]
> > _raw_spin_lock() {
> > preempt_count_add() {
> > do_raw_spin_lock() {
> > update_rq_clock();
> >
> > Where it should look like:
> >
> > _raw_spin_lock() {
> > preempt_count_add();
> > do_raw_spin_lock();
> > }
> > update_rq_clock();
>
> If set_graph_notrace works correctly, it should be just:
>
> update_rq_clock();
Which is what it should look like after patch 8. But I didn't mark 8 as
stable as that's more of a feature. As wakeup and irqsoff doesn't use
notrace yet. Yeah, notrace may break it a bit, but since this is the
first someone noticed it, I don't think it's used much.
I wanted the simplest fix for stable.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html