Re: [2.6.34-git8][regression] massive polling problems with udevdand other processes

[Eric Paris]

On Sun, 2010-05-23 at 22:20 +0200, Alessandro Suardi wrote:
> On Sun, May 23, 2010 at 1:25 AM, Eric Paris <eparis@xxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/