On Tue, 2005-02-22 at 10:18 -0500, Stephen Smalley wrote: > Hmmm...selinux-stack.patch and stacker_rcu_test.txt is showing up empty > when I download it; possibly just not propagated to all mirrors yet. It > would be easier if there was a single tarball with all of the files in > each release. I'll put up a tarball right now. > > 2. lsm-chain.patch: removed rwlock from security_set_value, > > security_get_value, and security_del_value operations. It is > > expected that security_del_value is only called from the > > security_free_* operation (ie security_free_inode), and that > > security_set_value only be called from security_alloc_*. > > A new, spinlock-protected function, security_add_value, can > > be used to add a security value at a later time. Look at > > the digsig.c.patch for sample usage. > > I'm not sure I understand why it would be safe to use this new function > without also taking the same spinlock for calls to the other functions. > In which case you might as well defer all locking to the caller (i.e. > the security module), and let the caller lock and unlock around the > calls to security_set_value() rather than introducing a separate > function. The spinlock prevents two simultaneous writers, and no one can delete until the kernel object is freed, so the only concern is processes walking the ->security chain while an object is being inserted. Those should be safe because security_add_value() uses hlist_add_head_rcu, which is safe for racing traversals. Is there another locking issue I'm ignoring? > > 7. selinux-stack.patch: Main difference is that when selinux > > is compiled in, the stackable capabilities module (cap_stack.ko) > > is now required. > > And stacker too? Oops, no, but obviously that's needed. The new version I put up this morning will have that. thanks, -serge -- Serge Hallyn <serue@private>
This archive was generated by hypermail 2.1.3 : Tue Feb 22 2005 - 07:47:42 PST