linux-kernel - Re: [2.6.34-git8][regression] massive polling problems with udevd and other processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 23 May 2010 19:49:01 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Alessandro Suardi <alessandro.suardi@...il.com>
Cc:	Eric Paris <eparis@...isplace.org>,
	Al Viro <viro@...iv.linux.org.uk>, walt <w41ter@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6.34-git8][regression] massive polling problems with udevd
 and  other processes

On Sun, 2010-05-23 at 22:20 +0200, Alessandro Suardi wrote:
> On Sun, May 23, 2010 at 1:25 AM, Eric Paris <eparis@...hat.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@...f ~]# 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@...f ~]# 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/