http://www.livejournal.com/users/james_morris/2153.html *AVC operation and analysis* To understand this, here's a brief explanation of how the core of the SELinux code works. SELinux uses a series of hooks (via LSM) at strategic points within the kernel. These hooks are used to divert the normal flow of the kernel into a security checking mechanism called the Access Vector Cache (AVC). The AVC contains cached permission checks performed against the system's security policy. As the working set of permission checks for a given workload is typically quite small, having them cached allows SELinux to scale virtually independently to the size of the security policy. For the vast majority of cases, an SELinux permission check is a quick cache lookup rather than a search of the entire security policy database. [...] *Solution: RCU* A few attempts had been made at "fixing" or getting rid of the AVC lock, using reader/writer lock variants and per-cpu techniques. Neither worked very well. Kaigai's patch, however, utilized RCU <http://lse.sourceforge.net/locking/rcupdate.html>, a mechanism which allows lockless reads and the elimination of atomic operations in read paths. As the AVC is overwhelmingly read-only on a typical system, RCU turned out to be an ideal method for removing the AVC lock completely. (about RCU: Read-Copy Update is one such mutual exclusion method where readers (threads trying to access, but not modify the data) can access the shared data without acquiring any conventional lock.) --- Could a similar idea/approach ascache security lookups + Rcu similar thing be useful to Zope or "I'm totally missing the point? (tm)"? :)