[Zope] An idea about the overhead of the security policy in Zope

[Yuri]

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)"? :)