On Mon, Jul 04, 2005 at 03:06:46PM -0500, [EMAIL PROTECTED] wrote: > > You are calling __symbol_get("ops"). > > > > Maybe (/probably :-)) I'm totally misunderstanding what you are doing but: > > a) I would have thought you would need to call symbol_get on the name the > > caller was passing, i.e symbol_get(capability_security_ops) > > b) The module registering these ops would need to EXPORT_SYMBOL this name. > > c) mod->state is MODULE_STATE_COMING right before the call to mod->init > > in sys_init_module which causes any symbol_gets() to return 0 (not that > > you actually care about the return value, only it's side effect) > > d) I don't see anything in this code path that would incr a ref on the > > registering module as a side effect of returning the sym. > > __symbol_get should eventually call try_module_get, which increments the > use count, right?
Duh, I missed the call to try_module_get, probably because it's right below the 'if (mod && mod->state == MODULE_STATE_COMING) return 0;' :-) in strong_try_module_get (2.6.13-rc1) mod->state is MODULE_STATE_COMING until after mod->init returns and since you are calling __symbol_get indirectly from the modules init routine, bammo. > Any suggestions on a good way to do what I wanted to do? Frankly a > new LSM hook seems the cleanest solution. Or, I could ramp up the > locking and permit module deletion, probably at a bit of performance > cost. Or I could just count on modules doing a symbol_get on > themselves? I think any symbol_get is problematic given the above. I was thinking you could wrap mod_reg_security but it would still need to be called from within the modules init fn. I'm going to have to give it some thought, but a new rmmod hook does seem a good solution off the top of my head. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/