massive polling problems with udevd and other processes
in [Kernel]
|
Prev: [RFC PATCH] irq: handle private interrupt registration
Next: i915/intel_sdvo: remove unneeded null check
From: Alessandro Suardi on 26 May 2010 17:10 On Mon, May 24, 2010 at 1:49 AM, Eric Paris <eparis(a)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(a)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(a)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(a)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") -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alessandro Suardi on 28 May 2010 21:30
On Wed, May 26, 2010 at 11:01 PM, Alessandro Suardi <alessandro.suardi(a)gmail.com> wrote: > On Mon, May 24, 2010 at 1:49 AM, Eric Paris <eparis(a)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(a)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(a)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(a)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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |