We found that all .38+ kernels with CONFIG_SECURITY just enables -- but not even any security module active -- are slower than .37. And also they don't really scale on larger machines. CONFIG_SECURITY is a quite common configuration, so this was seen multiple times. The problem is that with CONFIG_SECURITY every directory permission check will drop out of the RCU walk and redo a bunch of work (and not scale of course), just in case the security module cannot handle it. This patchkit tries to address this. First it moves the check for RCU walks into the low level security module, so for the CONFIG_SECURITY=y selinux=0 at runtime case you always get full performance. This is an independent patch. Then it turned out that the two security modules who use the inode_exec_permission hook that impacts dcache walking -- SMACK and selinux -- already use RCU internally. So I added two followon patches that make them not drop out of the RCU walk, as long as they stay in their RCU "fast" path. For selinux this means a cache hit only and no audit event. For smack it means any check as long as auditing is disabled. I didn't find good test suites for the security modules, so there wasn't a lot of testing on this unfortunately (the selinux one for LTP doesn't seem to work). Some close review of these changes is needed. On the other hand the VFS changes itself are very straight forward and the 1/1 patch is very straight forward (and a win in itself) The bottom line is with this patchkit a CONFIG_SECURITY=y kernel has as good VFS performance as a kernel with CONFIG_SECURITY disabled. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
