Hi David, thanks for your comments. Your lockless solution was definately nifty. I didn't switch it out lightly... Quoting David A. Wheeler (dwheeler@private): > This speed-up does have a cost: it means that > removing LSM modules becomes a two-step operation, > not a one-step operation. > You have to deactivate a module, wait for a while, > and THEN if you care about 1K-overheads remove the module > (I recommend skipping the second step). It was tempting to leave it this way :) but I really didn't like tossing out memory like that, at least not until I made sure there was no other way. And I couldn't think up a clean solution to "wait a while". Once I get some other preliminaries worked out (hopefully enabling the "correct" behavior of stacker loading selinux + capabilities) I plan to do some performance results comparing the original lockless approach vs my rcu approach to see what the impact really is. For the moment, I felt that a simple, clean RCU implementation would be most likely to be acceptable to the kernel community. Using the common APIs also makes it easier for others to read my code and spot my bugs. If the impact turns out to be significant, I'll certainly have to rethink my approach. I am also very interested in comments about the locking on kernel object security fields in lsm-chain.patch. I would like to use RCU there, but this seems to require more work from the security modules themselves. I prefer to present them with a simple "security_set_value()" type of API as the current patch does (at the cost of using a rwlock). thanks, -serge
This archive was generated by hypermail 2.1.3 : Mon Dec 20 2004 - 17:07:29 PST