Messages in this thread | | | Date | Mon, 29 Sep 2008 10:27:22 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] markers: fix unregister bug and reenter bug |
| |
* Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
> unregister bug: > > codes using makers are typically calling marker_probe_unregister() > and then destroying the data that marker_probe_func needs(or > unloading this module). This is bug when the corresponding > marker_probe_func is still running(on other cpus), > it is using the destroying/ed data. > > we should call synchronize_sched() after marker_update_probes(). > > reenter bug: > > marker_probe_register(), marker_probe_unregister() and > marker_probe_unregister_private_data() are not reentrant safe > functions. these 3 functions release markers_mutex and then > require it again and do "entry->oldptr = old; ...", but entry->oldptr > maybe is using now for these 3 functions may reenter when markers_mutex > is released. > > we use synchronize_sched() instead of call_rcu_sched() to fix > this bug. actually we can do: > " > if (entry->rcu_pending) > rcu_barrier_sched(); > " > after require markers_mutex again. but synchronize_sched() > is better and simpler. For these 3 functions are not critical path. > > Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
applied to tip/tracing/markers, thanks!
Mathieu, i've reactivated tip/tracing/markers for linux-next integration, it propagates into auto-ftrace-next. Tracepoints are what we use in the scheduler/etc. in tip/master, but until there's marker use elsewhere there's no reason not to apply fix patches.
Ingo
| |