Messages in this thread | | | Date | Thu, 27 Aug 2009 11:11:18 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH] tracing/profile: Fix profile_disable vs module_unload |
| |
* Steven Rostedt (rostedt@goodmis.org) wrote: > > On Thu, 27 Aug 2009, Mathieu Desnoyers wrote: > > > Looks good. Just don't forget to eventually add the "synchronize" calls > > between tracepoint unregistration and the removal of their module. There > > is a race condition in the way you do it currently. > > I'm trying to figure out the race here. What will disappear in the > tracepoint? Could you give a brief example of the issue.
Sure,
Let's say we have a tracepoint in module instrumented.c, and a probe in module probe.c. The probe is registered by module probe.c init through the tracepoint infrastructure to connect to the tracepoint in instrumented.c. Unregistration is done in probe.c module exit.
As the instrumented code get executed (let's say periodically), it calls the connected probe. Preemption is disabled around the call.
If you unload the probe.c module, the module exit will unregister the probe, but the probe code can still be in use by another CPU. You have to wait for quiescent state with the tracepoint synchronize (which is just a wrapper over synchronize_sched() before you are allowed to complete module unload. Otherwise, you will end up reclaiming module memory that is still used by probe execution.
A test-case for this would be to create a probe with a delay in it, and an instrumented module calling the instrumentation in a loop. On a SMP system, running the instrumented code and probe load/unload in loops should trigger this race.
Mathieu
> > Thanks, > > -- Steve > >
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |