Re: [patch 5/12] lsm stacking v0.2: actual stacker module

serge
2005-07-04T20:10:27Z

Quoting Tony Jones (tonyj@suse.de):
> On Mon, Jul 04, 2005 at 06:51:35AM -0500, serge@hallyn.com wrote:
>
> > > I don't think your symbol_get() is doing what you think it is ;-)
>
> > Hmm, I wonder whether something changed. It shouldn't be possible to
> > rmmod module b if module a has done a symbol_get on it...
>
> Are you thinking of resolve_symbol rather than get_symbol?
>
> 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?

But I'm completely misusing symbol_get - as you say, that is supposed
to be "symbol_name", not a pointer to the symbol.

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?

thanks,
-serge