Re: LSM stacker update

From: Stephen Smalley (sds@private)
Date: Thu Feb 03 2005 - 08:09:02 PST


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