* [2.6.34-git8][regression] massive polling problems with udevd and other processes @ 2010-05-22 19:35 Shawn Starr 2010-05-22 20:21 ` walt 0 siblings, 1 reply; 11+ messages in thread From: Shawn Starr @ 2010-05-22 19:35 UTC (permalink / raw) To: Linux Kernel Mailing List Just built today's snapshot from linus's tree and have problems with udev using 100% cpu and KDE processes also pegging cpus. This is with Fedora 13 + snapshot kernel from git. Anyone else noticing this? Thanks, Shawn. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-22 19:35 [2.6.34-git8][regression] massive polling problems with udevd and other processes Shawn Starr @ 2010-05-22 20:21 ` walt 2010-05-22 20:44 ` Al Viro 0 siblings, 1 reply; 11+ messages in thread From: walt @ 2010-05-22 20:21 UTC (permalink / raw) To: linux-kernel On 05/22/2010 12:35 PM, Shawn Starr wrote: > Just built today's snapshot from linus's tree and have problems with udev > using 100% cpu and KDE processes also pegging cpus. > > This is with Fedora 13 + snapshot kernel from git. > > Anyone else noticing this? Yes, just bisected it to this: commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d Author: Eric Paris <eparis@> 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@> Signed-off-by: Al Viro <viro@> udevd is busy polling anon_inode: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME udevd 695 root txt REG 8,21 117632 1523956 /sbin/udevd udevd 695 root mem REG 8,21 51528 1234821 /lib64/libnss_files-2.11.1.so udevd 695 root mem REG 8,21 43376 2052251 /lib64/libnss_nis-2.11.1.so udevd 695 root mem REG 8,21 88880 2052264 /lib64/libnsl-2.11.1.so udevd 695 root mem REG 8,21 31432 1234823 /lib64/libnss_compat-2.11.1.so udevd 695 root mem REG 8,21 1399984 1234830 /lib64/libc-2.11.1.so udevd 695 root mem REG 8,21 128424 1234829 /lib64/ld-2.11.1.so udevd 695 root 0u CHR 1,3 0t0 147 /dev/null udevd 695 root 1u CHR 1,3 0t0 147 /dev/null udevd 695 root 2u CHR 1,3 0t0 147 /dev/null udevd 695 root 3u REG 0,14 1133 1670 /dev/.udev/queue.bin udevd 695 root 4u unix 0xffff88011f2b3c80 0t0 274 socket udevd 695 root 5u sock 0,5 0t0 275 can't identify protocol udevd 695 root 6r REG 0,8 0 17 anon_inode udevd 695 root 7u REG 0,8 0 17 anon_inode udevd 695 root 8u unix 0xffff88011f2b3980 0t0 276 socket udevd 695 root 9u unix 0xffff88011f2b3680 0t0 277 socket poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, -1) = 1 ([{fd=6, revents=POLLIN}]) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-22 20:21 ` walt @ 2010-05-22 20:44 ` Al Viro 2010-05-22 21:10 ` walt 2010-05-22 22:59 ` Eric Paris 0 siblings, 2 replies; 11+ messages in thread From: Al Viro @ 2010-05-22 20:44 UTC (permalink / raw) To: walt; +Cc: linux-kernel On Sat, May 22, 2010 at 01:21:19PM -0700, walt wrote: > On 05/22/2010 12:35 PM, Shawn Starr wrote: > >Just built today's snapshot from linus's tree and have problems with udev > >using 100% cpu and KDE processes also pegging cpus. > > > >This is with Fedora 13 + snapshot kernel from git. > > > >Anyone else noticing this? > > Yes, just bisected it to this: > > commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d > Author: Eric Paris <eparis@> > Date: Fri May 14 11:44:10 2010 -0400 > > anon_inode: set S_IFREG on the anon_inode Cute... Frankly, I'd be fine with just reverting that one and teaching selinux to STFU. However, I wonder what specifically is getting polled. Which anon_inode users? Does anybody have strace handy? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-22 20:44 ` Al Viro @ 2010-05-22 21:10 ` walt 2010-05-22 22:59 ` Eric Paris 1 sibling, 0 replies; 11+ messages in thread From: walt @ 2010-05-22 21:10 UTC (permalink / raw) To: linux-kernel On 05/22/2010 01:44 PM, Al Viro wrote: > On Sat, May 22, 2010 at 01:21:19PM -0700, walt wrote: >> On 05/22/2010 12:35 PM, Shawn Starr wrote: >>> Just built today's snapshot from linus's tree and have problems with udev >>> using 100% cpu and KDE processes also pegging cpus. >>> >>> This is with Fedora 13 + snapshot kernel from git. >>> >>> Anyone else noticing this? >> >> Yes, just bisected it to this: >> >> commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d >> Author: Eric Paris<eparis@> >> Date: Fri May 14 11:44:10 2010 -0400 >> >> anon_inode: set S_IFREG on the anon_inode > > Cute... Frankly, I'd be fine with just reverting that one and teaching > selinux to STFU. However, I wonder what specifically is getting polled. > Which anon_inode users? > > Does anybody have strace handy? I included only one of thousands of identical lines from strace of udevd at the bottom of my previous post: poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, -1) = 1 ([{fd=6, revents=POLLIN}]) Let me know if that's not what you need. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-22 20:44 ` Al Viro 2010-05-22 21:10 ` walt @ 2010-05-22 22:59 ` Eric Paris 2010-05-22 23:25 ` Eric Paris 2010-05-23 18:18 ` walt 1 sibling, 2 replies; 11+ messages in thread From: Eric Paris @ 2010-05-22 22:59 UTC (permalink / raw) To: Al Viro; +Cc: walt, linux-kernel, eparis On Sat, May 22, 2010 at 4:44 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: > On Sat, May 22, 2010 at 01:21:19PM -0700, walt wrote: >> On 05/22/2010 12:35 PM, Shawn Starr wrote: >> >Just built today's snapshot from linus's tree and have problems with udev >> >using 100% cpu and KDE processes also pegging cpus. >> > >> >This is with Fedora 13 + snapshot kernel from git. >> > >> >Anyone else noticing this? >> >> Yes, just bisected it to this: >> >> commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d >> Author: Eric Paris <eparis@> >> Date: Fri May 14 11:44:10 2010 -0400 >> >> anon_inode: set S_IFREG on the anon_inode > > Cute... Frankly, I'd be fine with just reverting that one and teaching > selinux to STFU. However, I wonder what specifically is getting polled. > Which anon_inode users? On my system udev has both inotify and signalfd open. He's asking for more of the strace. If the ONLY thing that udev is doing is polling with no other syscalls at all it's a udev problem (although maybe one where we have to maintain bug for bug compatibility. Can you show us a more lines of strace context and the output of ls -l /proc/$PID/fd ? That should give us a better idea what udev is doing and which anon_inode we are dealing with. -Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-22 22:59 ` Eric Paris @ 2010-05-22 23:25 ` Eric Paris 2010-05-23 20:20 ` Alessandro Suardi 2010-05-23 18:18 ` walt 1 sibling, 1 reply; 11+ messages in thread From: Eric Paris @ 2010-05-22 23:25 UTC (permalink / raw) To: Eric Paris; +Cc: Al Viro, walt, linux-kernel On Sat, 2010-05-22 at 18:59 -0400, Eric Paris wrote: > On Sat, May 22, 2010 at 4:44 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Sat, May 22, 2010 at 01:21:19PM -0700, walt wrote: > >> On 05/22/2010 12:35 PM, Shawn Starr wrote: > >> >Just built today's snapshot from linus's tree and have problems with udev > >> >using 100% cpu and KDE processes also pegging cpus. > >> > > >> >This is with Fedora 13 + snapshot kernel from git. > >> > > >> >Anyone else noticing this? > >> > >> Yes, just bisected it to this: > >> > >> commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d > >> Author: Eric Paris <eparis@> > >> Date: Fri May 14 11:44:10 2010 -0400 > >> > >> anon_inode: set S_IFREG on the anon_inode > > > > Cute... Frankly, I'd be fine with just reverting that one and teaching > > selinux to STFU. However, I wonder what specifically is getting polled. > > Which anon_inode users? > > On my system udev has both inotify and signalfd open. He's asking for > more of the strace. If the ONLY thing that udev is doing is polling > with no other syscalls at all it's a udev problem (although maybe one > where we have to maintain bug for bug compatibility. > > Can you show us a more lines of strace context and the output of ls -l > /proc/$PID/fd ? That should give us a better idea what udev is doing > and which anon_inode we are dealing with. I'm wondering if this isn't a udev bug brought on by the combination of: commit c44dcc56d2b5c79ba3063d20f76e5347e2e418f6 Author: Al Viro <viro@zeniv.linux.org.uk> Date: Thu Feb 11 02:24:46 2010 -0500 switch inotify_user to anon_inode Signed-off-by: Al Viro <viro@zeniv.linux.org.uk and a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d (the commit in question). Before c44dcc56 the inotify inode would have been an S_IFDIR and maybe for that reason wouldn't have made it into the udev polling set? The inotify inode would have been nothing after c44dcc56 (obviously) and now that it is S_IFREG maybe udev is putting it in the polling set for some reason.... I'm feeling like this is a udev bug, but the only fix is going to be to revert and paper over anything else that has problems with (mode & S_IFMNT) == 0 -Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-22 23:25 ` Eric Paris @ 2010-05-23 20:20 ` Alessandro Suardi 2010-05-23 23:49 ` Eric Paris 0 siblings, 1 reply; 11+ messages in thread From: Alessandro Suardi @ 2010-05-23 20:20 UTC (permalink / raw) To: Eric Paris; +Cc: Eric Paris, Al Viro, walt, linux-kernel On Sun, May 23, 2010 at 1:25 AM, Eric Paris <eparis@redhat.com> wrote: > On Sat, 2010-05-22 at 18:59 -0400, Eric Paris wrote: >> On Sat, May 22, 2010 at 4:44 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: >> > On Sat, May 22, 2010 at 01:21:19PM -0700, walt wrote: >> >> On 05/22/2010 12:35 PM, Shawn Starr wrote: >> >> >Just built today's snapshot from linus's tree and have problems with udev >> >> >using 100% cpu and KDE processes also pegging cpus. >> >> > >> >> >This is with Fedora 13 + snapshot kernel from git. >> >> > >> >> >Anyone else noticing this? >> >> >> >> Yes, just bisected it to this: >> >> >> >> commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d >> >> Author: Eric Paris <eparis@> >> >> Date: Fri May 14 11:44:10 2010 -0400 >> >> >> >> anon_inode: set S_IFREG on the anon_inode >> > >> > Cute... Frankly, I'd be fine with just reverting that one and teaching >> > selinux to STFU. However, I wonder what specifically is getting polled. >> > Which anon_inode users? >> >> On my system udev has both inotify and signalfd open. He's asking for >> more of the strace. If the ONLY thing that udev is doing is polling >> with no other syscalls at all it's a udev problem (although maybe one >> where we have to maintain bug for bug compatibility. >> >> Can you show us a more lines of strace context and the output of ls -l >> /proc/$PID/fd ? That should give us a better idea what udev is doing >> and which anon_inode we are dealing with. > > I'm wondering if this isn't a udev bug brought on by the combination of: > > commit c44dcc56d2b5c79ba3063d20f76e5347e2e418f6 > Author: Al Viro <viro@zeniv.linux.org.uk> > Date: Thu Feb 11 02:24:46 2010 -0500 > > switch inotify_user to anon_inode > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk > > and a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d (the commit in question). > Before c44dcc56 the inotify inode would have been an S_IFDIR and maybe > for that reason wouldn't have made it into the udev polling set? The > inotify inode would have been nothing after c44dcc56 (obviously) and now > that it is S_IFREG maybe udev is putting it in the polling set for some > reason.... > > I'm feeling like this is a udev bug, but the only fix is going to be to > revert and paper over anything else that has problems with > (mode & S_IFMNT) == 0 > > -Eric Same issue here with -git8 and udevd... [root@duff ~]# cat udevd.ps.out root 1734 95.4 0.0 11336 1464 ? R<s 22:14 2:11 /sbin/udevd -d root 2163 0.0 0.0 12388 2600 ? S< 22:14 0:00 /sbin/udevd -d root 2277 0.0 0.0 12256 2472 ? S< 22:14 0:00 /sbin/udevd -d root 2282 0.0 0.0 12256 2396 ? S< 22:14 0:00 /sbin/udevd -d root 2283 0.0 0.0 11332 1376 ? S< 22:14 0:00 /sbin/udevd -d root 2293 0.0 0.0 11332 1364 ? S< 22:14 0:00 /sbin/udevd -d root 3082 0.0 0.0 102796 784 tty2 S+ 22:16 0:00 grep udevd [root@duff ~]# cat udevd.proc.pid.fd.out total 0 lrwx------. 1 root root 64 2010-05-23 22:15 0 -> /dev/null lrwx------. 1 root root 64 2010-05-23 22:15 1 -> /dev/null lrwx------. 1 root root 64 2010-05-23 22:15 2 -> /dev/null lrwx------. 1 root root 64 2010-05-23 22:15 3 -> /dev/.udev/queue.bin lrwx------. 1 root root 64 2010-05-23 22:15 4 -> socket:[6579] lrwx------. 1 root root 64 2010-05-23 22:15 5 -> socket:[6580] lr-x------. 1 root root 64 2010-05-23 22:15 6 -> anon_inode:inotify lrwx------. 1 root root 64 2010-05-23 22:15 7 -> anon_inode:[signalfd] lrwx------. 1 root root 64 2010-05-23 22:15 8 -> socket:[6581] lrwx------. 1 root root 64 2010-05-23 22:15 9 -> socket:[6582] [root@duff ~]# head -30 udevd.strace.log Process 1734 attached - interrupt to quit ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 --alessandro "There's always a siren singing you to shipwreck" (Radiohead, "There There") ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-23 20:20 ` Alessandro Suardi @ 2010-05-23 23:49 ` Eric Paris 2010-05-26 21:01 ` Alessandro Suardi 0 siblings, 1 reply; 11+ messages in thread From: Eric Paris @ 2010-05-23 23:49 UTC (permalink / raw) To: Alessandro Suardi; +Cc: Eric Paris, Al Viro, walt, linux-kernel On Sun, 2010-05-23 at 22:20 +0200, Alessandro Suardi wrote: > On Sun, May 23, 2010 at 1:25 AM, Eric Paris <eparis@redhat.com> wrote: > > I'm feeling like this is a udev bug, but the only fix is going to be to > > revert and paper over anything else that has problems with > > (mode & S_IFMNT) == 0 > > > > -Eric > [root@duff ~]# cat udevd.proc.pid.fd.out > lr-x------. 1 root root 64 2010-05-23 22:15 6 -> anon_inode:inotify > lrwx------. 1 root root 64 2010-05-23 22:15 7 -> anon_inode:[signalfd] > [root@duff ~]# head -30 udevd.strace.log > Process 1734 attached - interrupt to quit > poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) > ioctl(6, FIONREAD, [0]) = 0 Well at least I see what is wrong. Before the change ioctl(FIONREAD) would go down this code path: sys_ioctl() do_vfs_ioctl() vfs_ioctl() filp->f_ops->ioctl() inotify_ioctl() returns the answer. After the change we instead get: sys_ioctl() do_vfs_ioctl() file_ioctl() which would return put_user(i_size_read(inode) - filp->f_pos, p) If there is no rule that all inodes must be of a known S_IFMNT then I guess the best fix is to just revert and I'll fix up the symptoms. If there is such an unwritten rule (which seems perfectly reasonable) we can either special case the anon_inode to push FIONREAD down to vfs_ioctl or move FIONREAD down to vfs_ioctl and force everyone else to implement it. Al? Maybe you have better ideas? -Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-23 23:49 ` Eric Paris @ 2010-05-26 21:01 ` Alessandro Suardi 2010-05-29 1:25 ` Alessandro Suardi 0 siblings, 1 reply; 11+ messages in thread From: Alessandro Suardi @ 2010-05-26 21:01 UTC (permalink / raw) To: Eric Paris; +Cc: Eric Paris, Al Viro, walt, linux-kernel On Mon, May 24, 2010 at 1:49 AM, Eric Paris <eparis@redhat.com> wrote: > On Sun, 2010-05-23 at 22:20 +0200, Alessandro Suardi wrote: >> On Sun, May 23, 2010 at 1:25 AM, Eric Paris <eparis@redhat.com> wrote: > >> > I'm feeling like this is a udev bug, but the only fix is going to be to >> > revert and paper over anything else that has problems with >> > (mode & S_IFMNT) == 0 >> > >> > -Eric > >> [root@duff ~]# cat udevd.proc.pid.fd.out >> lr-x------. 1 root root 64 2010-05-23 22:15 6 -> anon_inode:inotify >> lrwx------. 1 root root 64 2010-05-23 22:15 7 -> anon_inode:[signalfd] > >> [root@duff ~]# head -30 udevd.strace.log >> Process 1734 attached - interrupt to quit >> poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) >> ioctl(6, FIONREAD, [0]) = 0 > > Well at least I see what is wrong. Before the change ioctl(FIONREAD) > would go down this code path: > > sys_ioctl() > do_vfs_ioctl() > vfs_ioctl() > filp->f_ops->ioctl() > inotify_ioctl() > returns the answer. > > After the change we instead get: > > sys_ioctl() > do_vfs_ioctl() > file_ioctl() > which would return put_user(i_size_read(inode) - filp->f_pos, p) > > If there is no rule that all inodes must be of a known S_IFMNT then I > guess the best fix is to just revert and I'll fix up the symptoms. If > there is such an unwritten rule (which seems perfectly reasonable) we > can either special case the anon_inode to push FIONREAD down to > vfs_ioctl or move FIONREAD down to vfs_ioctl and force everyone else to > implement it. > > Al? Maybe you have better ideas? 2.6.34-git11 with F12's just-updated udev-145-21.fc12.x86_64 is still exposing this issue... ATM I'm simply killing udevd right after booting, but it's definitely not an optimal solution. If more thought to a better fix is required, perhaps it's best for now to just revert the change that introduced the regression. thanks, --alessandro "There's always a siren singing you to shipwreck" (Radiohead, "There There") ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-26 21:01 ` Alessandro Suardi @ 2010-05-29 1:25 ` Alessandro Suardi 0 siblings, 0 replies; 11+ messages in thread From: Alessandro Suardi @ 2010-05-29 1:25 UTC (permalink / raw) To: Eric Paris; +Cc: Eric Paris, Al Viro, walt, linux-kernel On Wed, May 26, 2010 at 11:01 PM, Alessandro Suardi <alessandro.suardi@gmail.com> wrote: > On Mon, May 24, 2010 at 1:49 AM, Eric Paris <eparis@redhat.com> wrote: >> On Sun, 2010-05-23 at 22:20 +0200, Alessandro Suardi wrote: >>> On Sun, May 23, 2010 at 1:25 AM, Eric Paris <eparis@redhat.com> wrote: >> >>> > I'm feeling like this is a udev bug, but the only fix is going to be to >>> > revert and paper over anything else that has problems with >>> > (mode & S_IFMNT) == 0 >>> > >>> > -Eric >> >>> [root@duff ~]# cat udevd.proc.pid.fd.out >>> lr-x------. 1 root root 64 2010-05-23 22:15 6 -> anon_inode:inotify >>> lrwx------. 1 root root 64 2010-05-23 22:15 7 -> anon_inode:[signalfd] >> >>> [root@duff ~]# head -30 udevd.strace.log >>> Process 1734 attached - interrupt to quit >>> poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) = 1 ([{fd=6, revents=POLLIN}]) >>> ioctl(6, FIONREAD, [0]) = 0 >> >> Well at least I see what is wrong. Before the change ioctl(FIONREAD) >> would go down this code path: >> >> sys_ioctl() >> do_vfs_ioctl() >> vfs_ioctl() >> filp->f_ops->ioctl() >> inotify_ioctl() >> returns the answer. >> >> After the change we instead get: >> >> sys_ioctl() >> do_vfs_ioctl() >> file_ioctl() >> which would return put_user(i_size_read(inode) - filp->f_pos, p) >> >> If there is no rule that all inodes must be of a known S_IFMNT then I >> guess the best fix is to just revert and I'll fix up the symptoms. If >> there is such an unwritten rule (which seems perfectly reasonable) we >> can either special case the anon_inode to push FIONREAD down to >> vfs_ioctl or move FIONREAD down to vfs_ioctl and force everyone else to >> implement it. >> >> Al? Maybe you have better ideas? > > 2.6.34-git11 with F12's just-updated udev-145-21.fc12.x86_64 is still > exposing this issue... ATM I'm simply killing udevd right after booting, > but it's definitely not an optimal solution. > > If more thought to a better fix is required, perhaps it's best for now to > just revert the change that introduced the regression. > Issue appears to be gone for me on 2.6.34-git15. Thanks, --alessandro "There's always a siren singing you to shipwreck" (Radiohead, "There There") ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes 2010-05-22 22:59 ` Eric Paris 2010-05-22 23:25 ` Eric Paris @ 2010-05-23 18:18 ` walt 1 sibling, 0 replies; 11+ messages in thread From: walt @ 2010-05-23 18:18 UTC (permalink / raw) To: linux-kernel On 05/22/2010 03:59 PM, Eric Paris wrote: > On Sat, May 22, 2010 at 4:44 PM, Al Viro<viro@zeniv.linux.org.uk> wrote: >> On Sat, May 22, 2010 at 01:21:19PM -0700, walt wrote: >>> On 05/22/2010 12:35 PM, Shawn Starr wrote: >>>> Just built today's snapshot from linus's tree and have problems with udev >>>> using 100% cpu and KDE processes also pegging cpus. >>>> >>>> This is with Fedora 13 + snapshot kernel from git. >>>> >>>> Anyone else noticing this? >>> >>> Yes, just bisected it to this: >>> >>> commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d >>> Author: Eric Paris<eparis@> >>> Date: Fri May 14 11:44:10 2010 -0400 >>> >>> anon_inode: set S_IFREG on the anon_inode >> >> Cute... Frankly, I'd be fine with just reverting that one and teaching >> selinux to STFU. However, I wonder what specifically is getting polled. >> Which anon_inode users? > > On my system udev has both inotify and signalfd open. He's asking for > more of the strace. If the ONLY thing that udev is doing is polling > with no other syscalls at all it's a udev problem (although maybe one > where we have to maintain bug for bug compatibility. > > Can you show us a more lines of strace context and the output of ls -l > /proc/$PID/fd ? That should give us a better idea what udev is doing > and which anon_inode we are dealing with. strace is just very rapidly printing out thousands of identical lines like the one I posted earlier. Here is a new run: $head /tmp/strace ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, -1) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, -1) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, -1) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, -1) = 1 ([{fd=6, revents=POLLIN}]) ioctl(6, FIONREAD, [0]) = 0 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, -1) = 1 ([{fd=6, revents=POLLIN}]) Here is the fd listing for the udevd process: $cat /tmp/fd lrwx------ 1 root root 64 2010-05-23 08:38 0 -> /dev/null lrwx------ 1 root root 64 2010-05-23 08:38 1 -> /dev/null lrwx------ 1 root root 64 2010-05-23 08:38 2 -> /dev/null lrwx------ 1 root root 64 2010-05-23 08:38 3 -> /dev/.udev/queue.bin lrwx------ 1 root root 64 2010-05-23 08:38 4 -> socket:[274] lrwx------ 1 root root 64 2010-05-23 08:38 5 -> socket:[275] lr-x------ 1 root root 64 2010-05-23 08:38 6 -> anon_inode:inotify lrwx------ 1 root root 64 2010-05-23 08:38 7 -> anon_inode:[signalfd] lrwx------ 1 root root 64 2010-05-23 08:38 8 -> socket:[276] lrwx------ 1 root root 64 2010-05-23 08:38 9 -> socket:[277] ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-05-29 1:25 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-05-22 19:35 [2.6.34-git8][regression] massive polling problems with udevd and other processes Shawn Starr 2010-05-22 20:21 ` walt 2010-05-22 20:44 ` Al Viro 2010-05-22 21:10 ` walt 2010-05-22 22:59 ` Eric Paris 2010-05-22 23:25 ` Eric Paris 2010-05-23 20:20 ` Alessandro Suardi 2010-05-23 23:49 ` Eric Paris 2010-05-26 21:01 ` Alessandro Suardi 2010-05-29 1:25 ` Alessandro Suardi 2010-05-23 18:18 ` walt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).