Re: Make RCU dcache work with CONFIG_SECURITY=y

[Shaohua Li]

On Fri, 2011-04-22 at 08:23 +0800, Andi Kleen wrote:
> 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.
Great! This fully recovers the dbench regression I reported back:
http://marc.info/?l=linux-fsdevel&m=129591574123544&w=2
and we get a better throughput than 2.6.37

Thanks,
Shaohua


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/