[lkml]   [2011]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectMake RCU dcache work with CONFIG_SECURITY=y
    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


     \ /
      Last update: 2011-04-22 02:27    [W:0.019 / U:11.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site