Patrick, could you please check how you are disabling SELinux?
On my SL 6.2 (with a 2.6.32-220.23.1.el6.x86_64) test system, adding a boot
parameter of selinux=0 avoids creating the selinux_inode_security cache,
and that is what should happen by looking at the code.
The only other way that I am aware of for disabling SELinux (i.e.
completely, not just turning it into permissive mode) is to write to
/selinux/disable, likely from within initramfs, if
CONFIG_SECURITY_SELINUX_DISABLE is set and selinuxfs is mounted.
The former case should print a "SELinux: Disabled at boot." string on the
kernel ring buffer, and the latter should print a "SELinux: Disabled at
runtime." string. In the latter case the selinux_inode_security cache does
not get destroyed when SELinux is disabled, and a new object gets allocated
from selinux_inode_security for every new inode that gets created.
In case you are not aware, you can check the status of SELinux using
sestatus(8) from the policycoreutils package.
On Mon, Mar 31, 2014 at 7:33 AM, Patrick Farrell <paf(a)cray.com> wrote:
We at Cray recently noticed that on CentOS 6.4/5 servers even with
disabled there is still a noticeable amount of memory in use:
cat /proc/slabinfo | grep selinux
selinux_inode_security 7578 7579 72 53 1 : tunables 120 60
0 : slabdata 143 143 0
That's from an idle server, and it's not much usage (7579 objects, 72
bytes per object, ~ 0.5 MB of memory), but on an active server, there can
be millions of objects, leading to a few hundred MB of memory usage.
As far as I can tell, disabling selinux is required for Lustre servers to
function. When the kernel is built with SELinux disabled in the .config,
this memory usage goes away.
I'd like to propose changing the Lustre provided RHEL kernel config file
to not build SELINUX in to the kernel.
This won't affect clients unless they're running the patched kernel - only
the patched Lustre server kernels are changed by this, and as far as I
know, servers always have SELinux disabled.
I wanted to float this to a broad audience and get any objections before
creating an LU and pushing a patch to Gerrit. Does anyone have a reason
not to do this?
- Patrick Farrell
Patch, in essence:
@@ -4411,15 +4411,7 @@
# CONFIG_SECURITY_ROOTPLUG is not set
-# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
+# CONFIG_SECURITY_SELINUX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
HPDD-discuss mailing list