* [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 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
* 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
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).