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

[Steven Rostedt]

On Thu, 2012-06-14 at 19:48 -0400, Steven Rostedt wrote:

> I have several branches that I work on and when they are ready, I rebase
> them on top of tip, run a bunch of tests, and then push them out.

One more thing. I do run specific tests during development aimed at the
changes I make. I may rebase on top of tip afterward, run generic tests,
and then push out. These activities are not always done right after each
other. I probably screwed up by either cherry-picking or rebasing a
separate branch, noticing the bug (I remember fixing it before) but then
get side-tracked, and use the original branch that didn't have the fix.
Or it could have simply gotten reverted with a git reset --hard, where I
forgot to do the --amend. 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.

Anyway, I added to my generic tests: testing
 'echo schedule:traceon > set_ftrace_filter' as well as
 'echo schedule:traceoff > set_ftrace_filter' and make sure that they do
enable and disable tracing.

The traceon and traceoff triggers use tracing_on() and tracing_off()
underneath the covers. If they break, the test will fail (I tested the
broken patch and it does fail). This regression wont appear again.

Since the last time you've yelled at me, I've added a lot of stress
tests to ftrace. I test the tracing_on file to make sure it enables and
disables. But my generic tests did not include the internal
tracing_off() testing. My mistake, and yes I screwed up.

-- 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/