Hi to all, I will try to summarise in this post but first... >No, hooks are not allowed to sleep :) Some might be, but you'd have to >determine exactly which, and I decided it wasn't worth splitting up the >hooks that way. At least not yet. Is that really so? That really limits the functionality one can implement by using LSM hooks! So far I was not bitten by it and my hook sleep a *lot*. Even the sleep-while-spinlocked kernel debug code is silent. It would be great if some major LSM authority could comment on this. Guys, I don't mean to disrespect you (too much mafia films ;) as a non-authorities, it is just that I don't know who is the LSM designer and/or main maintainer. (but this is the right list!) That would really be a show-stopper "feature". So is there a point of me continuing? I am not sure but will nevertheless. I agree with David's point of treating writes (add/remove from chain) as extremely rare. But I do not like the "leave module loaded" idea. In the production environment, there must be a mechanism which enables updating critical OS parts without a reboot. LSM per se does not offer that, so the "stacker" module should remedy that. My first approach with rw semaphors showed to be deadlock prone on module unload. My second approach with RCU was invalidated by the fact that there is no sleeping allowed between rcu_read_lock() and rcu_read_unlock(). Therefore it seems I will have to take David ideas for lockless operation and disabling the module prior to unload. I guess I will try to return -EBUSY from mod_unreg_security() until module is dereferenced by everybody. To be completely transparent, module_exit of the module in question should disable itself and return -EBUSY on the first invocation. It should also return the same on all the subsequent invocations until the module is dereferenced. Do you think that could work? But the fact that LSM hooks might not be allowed to sleep is still a showstopper. In it's current state, LSM hooks do not provide sufficient functionality to implement some of the task required for a production environment. Comments anyone?
This archive was generated by hypermail 2.1.3 : Sun Dec 26 2004 - 18:23:57 PST