linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alessandro Suardi <alessandro.suardi@gmail.com>
To: Eric Paris <eparis@redhat.com>
Cc: Eric Paris <eparis@parisplace.org>,
	Al Viro <viro@zeniv.linux.org.uk>, walt <w41ter@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6.34-git8][regression] massive polling problems with udevd and  other processes
Date: Wed, 26 May 2010 23:01:40 +0200	[thread overview]
Message-ID: <AANLkTilIpEo3LSE9FuGpTh3OKHT12_v2rHRWUXRc_QhC@mail.gmail.com> (raw)
In-Reply-To: <1274658541.2810.58.camel@localhost>

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.

thanks,

--alessandro

 "There's always a siren singing you to shipwreck"

   (Radiohead, "There There")

  reply	other threads:[~2010-05-26 21:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-22 19:35 [2.6.34-git8][regression] massive polling problems with udevd and other processes Shawn Starr
2010-05-22 20:21 ` walt
2010-05-22 20:44   ` Al Viro
2010-05-22 21:10     ` walt
2010-05-22 22:59     ` Eric Paris
2010-05-22 23:25       ` Eric Paris
2010-05-23 20:20         ` Alessandro Suardi
2010-05-23 23:49           ` Eric Paris
2010-05-26 21:01             ` Alessandro Suardi [this message]
2010-05-29  1:25               ` Alessandro Suardi
2010-05-23 18:18       ` walt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTilIpEo3LSE9FuGpTh3OKHT12_v2rHRWUXRc_QhC@mail.gmail.com \
    --to=alessandro.suardi@gmail.com \
    --cc=eparis@parisplace.org \
    --cc=eparis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=w41ter@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).