Quoting tvrtko.ursulin@private (tvrtko.ursulin@private): > If I didn't miss something, you are firing away a call_rcu which will free > stacker structures associated with the module. But what is preventing the > stacked module itself to unload after mod_unreg_security (from it's > perspective) returns? Couldn't it unload itself while something is still > executing it's security hooks? Nope. It is removed from the list of modules; then we do call_rcu to call del_module. This means del_module won't be called until the next grace period. So if any process is using the module in a CALL_ALL (for instance), it will have incremented m->use before it rescheduled. After the grace period no one can reach m from the list of modules. So del_module will find (after the grace period) atomic_dec_and_test(m->use) to be non-zero if some module was using it. At first I was doing the atomic_dec_and_test in stacker_unregister before the call_rcu, but one of the RCU authors kindly pointed out that is in fact incorrect. -serge
This archive was generated by hypermail 2.1.3 : Thu Dec 23 2004 - 15:56:37 PST