Unnamed repository
d4ce7e5d97
Chaowang measured the selinux load_policy memory usage, it need ~50M It's too much under kdump 2nd kernel, it cause more OOM then before. Here is the findings from Vivek: - If we don't load policy or don't do restorecon, kernel automatically uses a label for file as specified by file /sys/fs/selinux/initial_contexts/file On my system this value is "system_u:object_r:file_t:s0". Kernel enforces this label on a file if it is not labeled. That's the reason that you see above label on vmcore file when selinux policy was not loaded in second kernel or restorecon was not done. Note: I did some testing with rhel6 and there also I see file_t context. Not sure why that's the case. - Relabeling of root file system over boot happens if there is a file /.autorelabel present. This file is touched by systemd service fedora-autorelabel-mark.service. And this file comes from initscritps package. So if this service thinks that system was booted with selinux disabled it will put this file on root and when next time system boots with selinux enabled, relabeling is enforced by fedora-autorelabel.service service. - In our case relabeling is not happening after saving vmcore because there does not seem be any fedora-autorelabel-mark.service running from initramfs context. Looks like this service runs after switching to real root. Aug 08 10:44:13 vm9-f19 systemd[1]: Started Mark the need to relabel after reboot. - selinux poicy is now loaded by systemd after root switch has taken place. Aug 08 10:44:10 vm9-f19 systemd[1]: Successfully loaded SELinux policy in 357.693ms. So now we know that why selinux relabeling is not taking place. Reason being that systemd service which marks the file system for autorelabeling does not run from initramfs context. And it might not make to run this service from initramfs context before switch root. In general it makes sense to first switch to root, load selinux policy if needed and then check whether to mark this filesystem for relabel or not. Ideally root is mourted read only before that. It is just that we break this rule for kdump. So as long as we make sure we relabel files created by kdump after booting back, things should be fine. Since we will relabel the vmcore dir after reboot so let's remove the selinux dracut module dependency to avoid load_policy in 2nd kernel. If in the future load_policy memory usage shrinks to an acceptable level or there's a better solution we can add selinux load_policy back later. Signed-off-by: Dave Young <dyoung@redhat.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> |
||
|---|---|---|
| po | ||
| .gitignore | ||
| 98-kexec.rules | ||
| dracut-kdump.sh | ||
| dracut-module-setup.sh | ||
| dracut-monitor_dd_progress | ||
| firstboot_kdump.py | ||
| kdump.conf | ||
| kdump.conf.5 | ||
| kdump.init | ||
| kdump.service | ||
| kdump.sysconfig | ||
| kdump.sysconfig.i386 | ||
| kdump.sysconfig.ia64 | ||
| kdump.sysconfig.ppc64 | ||
| kdump.sysconfig.s390x | ||
| kdump.sysconfig.x86_64 | ||
| kdumpctl | ||
| kexec-kdump-howto.txt | ||
| kexec-tools-2.0.3-build-makedumpfile-eppic-shared-object.patch | ||
| kexec-tools-2.0.3-disable-kexec-test.patch | ||
| kexec-tools-2.0.4-makedumpfile-Add-vmap_area_list-definition-for-ppc-ppc64.patch | ||
| kexec-tools.spec | ||
| mkdumprd | ||
| mkdumprd.8 | ||
| rhcrashkernel-param | ||
| sources | ||
| zanata-notes.txt | ||