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. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Thu Feb 03 2005 - 08:16:54 PST