linux-kernel - udev loops eating 100 % CPU [mmotm 2010-05-21-16-05]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 May 2010 14:12:39 +0200
From:	Jiri Slaby <jirislaby@...il.com>
To:	Eric Paris <eparis@...hat.com>
CC:	Al Viro <viro@...iv.linux.org.uk>,
	Kay Sievers <kay.sievers@...e.de>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: udev loops eating 100 % CPU [mmotm 2010-05-21-16-05]

Hi,

>From next/master:
commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d
Author: Eric Paris <eparis@...hat.com>
Date:   Fri May 14 11:44:10 2010 -0400

    anon_inode: set S_IFREG on the anon_inode

    anon_inode_mkinode() sets inode->i_mode = S_IRUSR | S_IWUSR;  This means
    that (inode->i_mode & S_IFMT) == 0.  This trips up some SELinux code
that
    needs to determine if a given inode is a regular file, a directory, etc.
    The easiest solution is to just make sure that the anon_inode also sets
    S_IFREG.

    Signed-off-by: Eric Paris <eparis@...hat.com>
    Signed-off-by: Al Viro <viro@...iv.linux.org.uk>





causes my udev and psi both eating 100 % CPU. When I revert that on the
top of mmotm 2010-05-21-16-05, the problem disappears.

These are red-numbered lines from perf:
    13.96%    udevd  [kernel.kallsyms]      [k] _raw_spin_unlock_irqrestore
    10.22%    udevd  [kernel.kallsyms]      [k] signalfd_poll
     7.82%    udevd  [kernel.kallsyms]      [k] system_call_after_swapgs
     6.33%    udevd  [kernel.kallsyms]      [k] do_sys_poll
     5.43%    udevd  udevd                  [.] 0x0000000000dc72


It loops with this strace:
ioctl(7, FIONREAD, [0])                 = 0
poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 5, 3000)
= 1 ([{fd=7, revents=POLLIN}])

where /proc/.../fd is:
lrwx------ 1 root root 64 May 25 14:06 0 -> /dev/null
lrwx------ 1 root root 64 May 25 14:06 1 -> /dev/null
lrwx------ 1 root root 64 May 25 14:06 10 -> socket:[1676]
lrwx------ 1 root root 64 May 25 14:06 2 -> /dev/null
lrwx------ 1 root root 64 May 25 14:06 3 -> /dev/.udev/queue.bin
lrwx------ 1 root root 64 May 25 14:06 4 -> socket:[1673]
l-wx------ 1 root root 64 May 25 14:06 5 -> /dev/blog
lrwx------ 1 root root 64 May 25 14:06 6 -> socket:[1674]
lr-x------ 1 root root 64 May 25 14:06 7 -> anon_inode:inotify
lrwx------ 1 root root 64 May 25 14:06 8 -> anon_inode:[signalfd]
lrwx------ 1 root root 64 May 25 14:06 9 -> socket:[1675]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/