On Fri, 2013-06-21 at 16:39 -0400, Steven Rostedt wrote: > On Fri, 2013-06-21 at 20:12 +0900, Masami Hiramatsu wrote: > > (2013/06/21 3:31), Tom Zanussi wrote: > > > The comment on the soft disable 'disable' case of > > > __ftrace_event_enable_disable() states that the soft disable bit > > > should be cleared in that case, but currently only the soft mode bit > > > is actually cleared. > > > > > > This essentially leaves the standard non-soft-enable enable/disable > > > paths as the only way to clear the soft disable flag, but the soft > > > disable bit should also be cleared when removing a trigger with '!'. > > > > Indeed, the soft-disabled flag may remain after the event itself > > disabled. However that soft-disabled flag will be cleared when > > the event is re-enabled. it seems no bad side-effect. > > > > Thus I doubt this patch is separately required. I guess this is > > required for adding new trigger flag, isn't it? :) > > Tom, I'm guessing Masami is correct here. It's needed for the trigger > work to work, correct? >
Well, the trigger should really work without this - this is basically just a cleanup I added because it bothered me that I couldn't completely revert the enable state back to the original state that existed before I added the trigger (by reverting the trigger using '!'). It also just seemed obviously correct from looking at the code as well (though I agree, it's hard to keep the state machine of that function in your head in order to prove it correct, and the straggling soft-disable state hasn't bothered anyone until now, so maybe it's not worth it..) In any case, if the SOFT_DISABLED bit is erroneously set but there are no triggers, it shouldn't be a problem, since the trigger calls would just return immediately, so not having this patch wouldn't break anything... Tom > Either way, I probably could add it as a clean up patch regardless. I'll > just have to test the hell out of it some more, as the accounting for > soft-disable vs real disable was a PITA. > > -- Steve > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
