Quoting Tony Jones ([email protected]):
> Hey Serge,
>
> 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... This may mean
more stringent locking will be required after all to support unloading.
That, or a rmmod lsm hook.
> > + * Add the stacked module (as specified by name and ops).
> > + * If the module is not compiled in, the symbol_get at the end will
> > + * prevent the the module from being unloaded.
> > +*/
> > +static int stacker_register (const char *name, struct security_operations *ops)
> > +{
> ...
> > + symbol_get(ops);
> > +
> > +out:
> > + spin_unlock(&stacker_lock);
> > + return ret;
> > +}
>
>
> Seemed useful to be able to view which modules had been unloaded.
> Easier to maintain them on their own list than to compute the difference
> of <stacked_modules> and <all_modules>. Patch attached, not sure if you
> are cool with reusing the 'unload' file.
No, that's good, thanks. Though I guess "unloading" of this type won't
be needed if true module deletion has to be supported.
> Apart from this, looks good. I ran it against our regression tests using
> AppArmor (SubDomain) composed with Capability and everything was functionally
> as expected. I still need to run it through our SMP stress tests.
Excellent :)
thanks,
-serge
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |