Messages in this thread | | | Subject | Re: [PATCH] tracing/profile: Fix profile_disable vs module_unload | From | Peter Zijlstra <> | Date | Wed, 26 Aug 2009 21:14:06 +0200 |
| |
On Wed, 2009-08-26 at 12:46 -0400, Mathieu Desnoyers wrote: > Registering tracepoints even when no tracepoint definition is currently > visible is the intended allowed behavior. Let's say we need to trace > something happening in module init: if we disallow registering the tp > callback before the module is initialized, we run in a chicken and egg > problem. > > So I am trying to figure out the problem source there. Is it that > modules containing the tp callbacks need to know if those are actually > connected to an instrumented module ? Or is it that the instrumented > module needs to know if a probe module is connected to is ? Or is it the > teardown of the probe module ? No refcount is needed there, because we > surround the probe call by preempt disable/enable, and we use > synchronize_sched() before removing the module which contains probe > callbacks. > > Mathieu-trying-to-figure-out-what-this-whole-thread-is-about :)
OK, so the whole point seems to be that tracepoints have the funny thing you describe above, whereas the things ftrace makes out of TRACE_EVENT() get instantiated along with modules.
The reason why I rejected the initial patch (and I still think that that fix is at the wrong layer) is that I, as a consumer of whatever TRACE_EVENT() offers, should never need to consider modules.
| |