* Francis Giraldeau ([email protected]) wrote: > Le 2012-06-26 08:40, Mathieu Desnoyers a écrit : > >> +/* > >> + * lttng_uevent_set_handler - set handler functions for uevent > >> + * > >> + * Access to handler code is protected with rwlock in order to > >> + * prevent the optional module to be removed while in use. > >> + */ > >> + > >> +void lttng_uevent_set_handler(write_ops_t handler) > >> +{ > >> + write_lock(&uevent_rwlock); > > > > write lock not necessary. > > > > if (!lttng_uevent_set_handler) > > release refcount in prior handler's module. > > > > then: > > take a refcount on the module that contains the handler address. > > (explicit) > > > The function now looks like this: > > void lttng_uevent_set_handler(struct file_operations *fops) > { > if (lttng_uevent_handler) { > module_put(lttng_uevent_handler->owner); > } > if (fops && try_module_get(fops->owner)) { > lttng_uevent_handler = fops; > return; > } > lttng_uevent_handler = NULL; > return; > } > > The problem with this approach is that lttng_uevent can't be unloaded > anymore: > > rmmod lttng_uevent > ERROR: Module lttng_uevent is in use > > The module lttng_uevent can't be unloaded without unloading the module > lttng_tracer. The function module_exit of lttng_uevent is never called, > such that there is a chicken-and-egg situation. This problem was solved > by using rwlock to access the handler pointer. In the rare event when > unload module would occur while a trace event is recorded, the write > lock was preventing to change the handler pointer while it's in use. But > maybe there is another way to do it?
Good point, circular dependency on the destructor is not good, because there is no way to unload the module. Another way to do it is to use RCU. module unload contains a synchronize_rcu() call, so you can protect your handler with: /* Using RCU to protect against module removal */ rcu_read_lock(); handler = rcu_dereference(lttng_uevent_handler); ret = handler(...))); rcu_read_unlock; return ret; Thanks, Mathieu > > Thanks! > > Francis Giraldeau > > _______________________________________________ > lttng-dev mailing list > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
