On Mon, 2005-01-31 at 15:33, Stephen Smalley wrote: > This would also mean that the performance and scalability overhead of > stacker has to be minimal, as it would effectively become a dependency > for normal use of SELinux. That may require revisiting the locking > scheme for the chained security objects. On this topic, if security_set_value* is only called from hooks like alloc_security where the kernel object is not yet accessible to other threads and if security_del_value* is only called from hooks like free_security where the last reference to the object has already been released, then why do you need locking in the security_[gs]et_value functions at all? The chains are per-object, and are only modified when the object is not accessible to other threads. This appears to be valid for usage by SELinux. Or am I missing something? -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Feb 01 2005 - 03:56:27 PST