Re: [PATCH] tracing: Fix the outmost stupidity of tracing_off()

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 2012-06-15 at 00:18 -0400, Steven Rostedt wrote:
> For testing something like this, I would have
> added tracing_off() in the code, and I do reset --hard to remove my
> testing code. If I made the fix and forgot to --amend it, the fix was
> lost.

I'm almost positive this is what happened.

tracing_off() is similar to trace_printk(), it's something that is
usually added during development and not something that is normally
executed in production. With an unmodified kernel, to test it, you need
to start tracing and trigger a crash and have ftrace_dump_on_opps set,
and have something to read it so that you know the tracing stopped. Not
very reliable, and not something to put into generic testing.

I forgot that the function tracer 'traceoff' trigger uses it, otherwise
I would have added that new test a while ago.

For my testing, I put in tracing_off() at various places in the kernel,
and made sure that it worked. I did see that it was broken before and
fixed it. But for some reason, maybe I was distracted by other work, I
never did the git commit --amend (similar to forgetting to do a quilt
refresh). All my tests worked, and I reverted the test code I added with
either a 'git reset --hard', or a 'git diff | patch -p1 -R', both of
which would have removed my fix.

I usually scan the 'git diff' before doing the revert, but as this
change was a one liner, it could easily have been missed.

The code I've been working on for the last few months was debugging the
breakpoint code, which, when it failed, triple faulted the box. Tracing
was never an option. Which means that I would not have played with
tracing_off() then. And the older code that I've been working with
(3.2-rt), did not have this bug.

Again, I know you are one of the biggest users of ftrace, and I'm very
sorry (and ashamed) that his bug got in and caused you a days worth of
frustration.

-- Steve