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] [day] [month] [year] [list]

Message-ID: <AANLkTim-WCcDr5_btk60kCf6FgDLaox6QK7rboY6-wd6@mail.gmail.com>
Date:	Sat, 29 May 2010 03:25:10 +0200
From:	Alessandro Suardi <alessandro.suardi@...il.com>
To:	Eric Paris <eparis@...hat.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 Wed, May 26, 2010 at 11:01 PM, Alessandro Suardi
<alessandro.suardi@...il.com> wrote:
> On Mon, May 24, 2010 at 1:49 AM, Eric Paris <eparis@...hat.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@...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?
>
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/