Bug 591813

There is very little chance this is an 'SELinux' bug.  The inode in question somehow does not have correct inode->i_mode flags.  The message:

unknown mode:600

means that the inode->i_mode == 0600  (octal)

Which means it was clearly not created properly (hint, it should have bits saying if this is a file, dir, chr, blk, sock, lnk, etc)

As long as it is as easy to reproduce as you say I'll see if we can't make the kernel dump a stack trace to figure out who is created these broken inodes....

-Eric

It was anon_inode:[signalfd] which sets inode->i_mode = S_IRUSR | S_IWUSR;  I added S_IFREG in there and it was able to run filecap -a without the SELinux spam.  I did see some console output:

PPP generic driver version 2.4.2
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk>
PM: Marking nosave pages: 000000000009f000 - 0000000000100000
PM: Marking nosave pages: 00000000bfff0000 - 0000000100000000
PM: Basic memory bitmaps created
PM: Basic memory bitmaps freed
PM: Marking nosave pages: 000000000009f000 - 0000000000100000
PM: Marking nosave pages: 00000000bfff0000 - 0000000100000000
PM: Basic memory bitmaps created
PM: Basic memory bitmaps freed

Which I assume is the result of opening some file in /proc or /sys and closing it.

If you're machine has any problems other than just the console spam please open a new BZ, and I'm going to use this one just to silence the SELinux console spam.

> If you're machine has any problems other than just the console spam please open
> a new BZ, and I'm going to use this one just to silence the SELinux console
> spam.    

Eric, if I let it run long enough the system crashed *every time* and I had to powercycle it as mentioned in the bug report. Tested on x84_64/bare and i386/kvm.
Logged messages are just a cosmetic issue.

I've been able to run filecap -a to completion 4 or 5 times after silencing the SELinux spam.  I'll attach the patch in question and send it towards upstream and rhkernel-list.  If you can reproduce with the patch hopefully we can open a new bug with information to point towards your problem.  Namely we need either the panic/oops backtrace or we need to make sure the watchdogs (nmi_watchdog) are on to catch hard lockups, or you need to collect sysrq-t before the reboot.  So we can figure out who should be looking for a problem.

Created attachment 414090 [details]
Test program to poke small parts of the system like filecap -a

This test program will emulate the behaviour of filecap -a only in a more directed manor.  You can run

./test /proc

to just troll through /proc (which should generate the SELinux SPAM)

you can run i through /sys and maybe hit on other problems.....

moving this bug to POST as I posted a fix for the anon_inode + SELinux issue.  If we can reproduce a crash and collect some info about it, lets open a new bug/clone this bug for that new issue.

(In reply to comment #7)
> moving this bug to POST as I posted a fix for the anon_inode + SELinux issue. 
> If we can reproduce a crash and collect some info about it, lets open a new
> bug/clone this bug for that new issue.    

Tried to collect some info with help of one our kernel qe guys, but without any success (bare metal). If it helps, we were able to reproduce the crash also with disabled SELinux. I'll try to reproduce it on a virt guest and try collect some info. Any ideas/suggestions are welcomed :)

Did you do it using filecap -a or using my program?

I would suggest you can make my program print the file it is about to deal with.  Then run it against /dev.  If that works run it against /sys.  I'm guessing it is one of those filesystems that you will run into your crash.  It might narrow it down to a particular file.

If that doesn't work you can run filecap under strace and you'll possibly learn the file in question (or at least a file close to it)......

Patch(es) available on kernel-2.6.32-28.el6

Tested on 2.6.32-28.el6.x86_64 and the system still crashes though "SELinux: Warning" messages are gone. Eric do you want me to open a separate bug for the "crash" part?

Before the crash following messages appeared in /var/log/messages:

May 24 11:13:53 godot kernel: iTCO_wdt: Unexpected close, not stopping watchdog!
May 24 11:13:53 godot kernel: PPP generic driver version 2.4.2
May 24 11:13:53 godot kernel: tun: Universal TUN/TAP device driver, 1.6
May 24 11:13:53 godot kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk>
May 24 11:13:53 godot kernel: iTCO_wdt: Unexpected close, not stopping watchdog!

I say we let this BZ just be for the SELinux printk spam as a patch was committed to fix that problem.  I'd suggest we open a new BZ for the crash, hopefully it can also contain more details on what is crashing the kernel by modifying the program in comment #6 with the changes and test suggested in comment #9

Verified on 2.6.32-28.el6.x86_64. SELinux warning messages / spam are now fixed. 
The kernel crash part opened as a separate bug 595673. You may close this bug, if no more testing is required.

Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.