Ok - I guess I should be able to just compile stacker as a module, and not load it, to get the numbers you're interested in. Let me see what that gets me this morning. It should be interesting to see how much more a hlist_add/hlist_del takes vs simple void* assignment. thanks, -serge Quoting Chris Wright (chrisw@private): > * Serge E. Hallyn (serue@private) wrote: > > Attached is a new implementation of the lsm stacking through chaining. > > This one is a little more intricate than the last, in that it is enabled > > when the stacker module is compiled in, but can otherwise be compiled out. > > Hmm, I'm not convinced that's a great idea. > > > The attached lmbench numbers show that the fedora setup of selinux + > > capabilities compiled in (and no stacker module) does not slow down at > > least this benchmark. Using the same modules but through stacker fares > > a bit worse. > > I'd hope that w/out stacker (with this configurable setup) the config'd > off it should completely go away. I'll have to look closer, but I wonder > what it would look like with it unconditionally enabled, yet not used (in > the SELinux case)? > > > Attached are the following files: > > lsm-chain.patch: implements the CONFIG-dependent use of hlist_heads for > > kernel object security structs. > > This worries me. Especially with security_t being conditionally defined > to two different datatypes. I think that would be rejected. > > thanks, > -chris > -- > Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net >
This archive was generated by hypermail 2.1.3 : Fri Nov 12 2004 - 04:30:26 PST