On Thu, 2005-02-03 at 11:09 -0500, Stephen Smalley wrote: > On Wed, 2005-02-02 at 11:00, Stephen Smalley wrote: > > Adding a small allocation to the existing object allocation path > > shouldn't be significant, vs. overhead on the security_get_value path > > which happens on every object operation. And the overhead on > > security_get_value will be significant - not only is there locking > > overhead, but you have to disable interrupts too. And the scalability > > impact will clearly be significant, at least on security_set_value. > > Possible alternatives to going completely lockless for [gs]et_value and > del_value (with the corresponding requirement that your set_value and > del_value functions only be called from alloc_security and > free_security) might be: > 1) Reduce the read_lock_irqsave/unlock_irqrestore to just > read_lock/unlock. That is safe as long as modules never attempt a > set_value or del_value from interrupt; as long as they only call > get_value from interrupt, there is no need to use the irq-safe read lock > variant. That will at least reduce the cost on the read path, although > there is still locking overhead there. > 2) Rewrite to use RCU. That makes get_value cheap, but still requires > locking for set_value and del_value, and it would still be a global lock > there. The biggest reason I didn't want to use RCU is the required cooperation from all modules. For the moment I'm working on the completely lockless variant. Unfortunately that means digsig has to be loaded very early, but other LSMs don't seem to be a problem. I did consider another variant: Stick with the lockless variant. Export a stacker_write_value_lock spinlock. A module which must add a symbol outside of the security_alloc_object hook has to grab that spinlock, then do the assignment in a manner safe to readers, ie blob->next = next; inode->i_security.next = blob; Readers are protected while walking the list. Ordinary writers are adding blobs only during security_alloc_object(), which is inherently protected from these writers. These writers are protected from each other by the spinlock. Does this seem like it might work? thanks, -serge -- Serge Hallyn <serue@private>
This archive was generated by hypermail 2.1.3 : Thu Feb 03 2005 - 08:51:21 PST