On Wed, 2004-10-27 at 07:13, Serge E. Hallyn wrote: > I always liked the trusted bsd approach of an array inode->i_security[NUM_LSMS] > better. but this is more flexible than that, while hopefully faster and cleaner > than the purely voluntary chaining approach. Did you ever try the hybrid approach suggested in http://marc.theaimsgroup.com/?l=linux-security-module&m=108852419220859&w=2? Two statically allocated entries for primary and secondary module, then voluntary chaining using a common header (possibly embedded). That seems like a more promising approach to me than the hashtable. > I was going to switch to seqlocks on the next version (It could be > too write-heavy for RCU). The spinlocks were only for the first version, > while testing on UP. Still has to be safe for hard and soft irq. > Do you have anything in mind for how to optimize for one LSM? By avoiding any change from the current situation when there is only one LSM. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 06:04:24 PDT