Messages in this thread | | | Date | Sat, 29 May 2010 03:25:10 +0200 | Subject | Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes | From | Alessandro Suardi <> |
| |
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") -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |