On Wed, 2013-07-03 at 11:42 +0900, Masami Hiramatsu wrote: > (2013/07/03 7:23), Oleg Nesterov wrote: > > On 07/02, Oleg Nesterov wrote: > >> > >> So please ignore modules ;) > > > > Or lets discuss the change above. > > No, I think this still doesn't ensure that we can remove dynamic > event safely. Since the event is related to several files under > events/ dir and buffer instances, someone can just stay open the > files while the event is removed and read/write it. > Perhaps, we need per-event_call refcounter not per-trace_array > one, and do as below.
Or both. I need the trace-array counter for rmdir, and don't want to check every event. But that doesn't mean we can't have a event counter. > > Open file: > -> lock event_mutex > -> find event_call and event_file > -> get event_call > -> unlock event_mutex > > Close: > -> lock event_mutex > -> put event_call > -> unlock event_mutex > > Remove event (via kprobe_events): > -> lock event_mutex > -> find event_call > -> -EBUSY if event is enabled or refcount != 0 > (here, no one accessing the event and not enabled) > -> unregister_kprobe > -> remove event > -> unlock event_mutex > > The key is holding event_mutex *and* getting refcount > under any operation. And this would be to the event call, not the event file itself, right? -- Steve > And of course, we can unregister the kprobe outside of > the event_mutex, but it still need a synchronize_sched > for safety. > > -> lock event_mutex > -> wait_for_rcu (to ensure no disabled kprobe accesses the event) > -> find event_call > -> -EBUSY if event is enabled or refcount != 0 > (here, no one accessing the event and not enabled) > -> remove event > -> unlock event_mutex > -> unregister_kprobe > > Thank you, > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
