summaryrefslogtreecommitdiffstats
path: root/security/tomoyo/Kconfig
diff options
context:
space:
mode:
authorEric Paris <eparis@redhat.com>2010-12-07 22:17:28 +0100
committerEric Paris <eparis@redhat.com>2010-12-07 22:44:01 +0100
commit73ff5fc0a86b28b77e02a6963b388d1dbfa0a263 (patch)
tree7b84f738078e6b96f6b35805c8b6c4fa699968ed /security/tomoyo/Kconfig
parentSELinux: do not compute transition labels on mountpoint labeled filesystems (diff)
downloadlinux-73ff5fc0a86b28b77e02a6963b388d1dbfa0a263.tar.xz
linux-73ff5fc0a86b28b77e02a6963b388d1dbfa0a263.zip
selinux: cache sidtab_context_to_sid results
sidtab_context_to_sid takes up a large share of time when creating large numbers of new inodes (~30-40% in oprofile runs). This patch implements a cache of 3 entries which is checked before we do a full context_to_sid lookup. On one system this showed over a x3 improvement in the number of inodes that could be created per second and around a 20% improvement on another system. Any time we look up the same context string sucessivly (imagine ls -lZ) we should hit this cache hot. A cache miss should have a relatively minor affect on performance next to doing the full table search. All operations on the cache are done COMPLETELY lockless. We know that all struct sidtab_node objects created will never be deleted until a new policy is loaded thus we never have to worry about a pointer being dereferenced. Since we also know that pointer assignment is atomic we know that the cache will always have valid pointers. Given this information we implement a FIFO cache in an array of 3 pointers. Every result (whether a cache hit or table lookup) will be places in the 0 spot of the cache and the rest of the entries moved down one spot. The 3rd entry will be lost. Races are possible and are even likely to happen. Lets assume that 4 tasks are hitting sidtab_context_to_sid. The first task checks against the first entry in the cache and it is a miss. Now lets assume a second task updates the cache with a new entry. This will push the first entry back to the second spot. Now the first task might check against the second entry (which it already checked) and will miss again. Now say some third task updates the cache and push the second entry to the third spot. The first task my check the third entry (for the third time!) and again have a miss. At which point it will just do a full table lookup. No big deal! Signed-off-by: Eric Paris <eparis@redhat.com>
Diffstat (limited to 'security/tomoyo/Kconfig')
0 files changed, 0 insertions, 0 deletions