That logic came out of long discussions with Paul McKenney and Dipankar Sarma. I'm quite certain that our two best options are to go with this approach, or to simply never unload any security_ops. We could allow for disabling of modules by setting a m->disabled flag and setting prev- >next = m->next. Unfortunately our automated test labs aren't handling selinux tests very well right now. Once that is resolved, I plan to do some heavy runs on UP vs SMP to see what the actual costs are. But maybe we just want to go with the disable-but-don't-remove option anyway, so the security_ops sticks around to handle free_inode_security etc? We could keep a second list of modules which keeps disabled modules and which is used for freeing only. This would require each module to either keep a serial number in the security structs in case it is reloaded, or refuse to be reloaded. -serge On Wed, 2005-02-02 at 08:46 -0500, Stephen Smalley wrote: > On Tue, 2005-02-01 at 09:33, Stephen Smalley wrote: > > Module removal has plenty of other > > safety issues already, doesn't it? > > On this topic, how valuable do you consider your current logic in the > stacker module for incrementing the use count on each stacked security > module while calling it? One of the stated purposes of RCU (per > Documentation/RCU/rcu.txt) is to allow RCU readers to avoid not only > lock acquisition but also other expensive operations like atomic > instructions. Having to perform an atomic_inc and atomic_dec_and_test > for each stacked security module seems unfortunate, especially for an > uncommon situation like module removal. > -- Serge Hallyn <serue@private>
This archive was generated by hypermail 2.1.3 : Wed Feb 02 2005 - 07:25:58 PST