From mboxrd@z Thu Jan  1 00:00:00 1970
From: md@Linux.IT (Marco d'Itri)
Date: Tue, 20 Oct 2009 18:04:50 +0000
Subject: Re: Bug#551743: udevd spawns numerous processes and eats up almost
Message-Id: <20091020180450.GA16875@bongo.bofh.it>
MIME-Version: 1
Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8"
List-Id: <linux-hotplug.vger.kernel.org>
To: linux-hotplug@vger.kernel.org


--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Oct 20, Torsten Crass <torsten.crass@eBiology.de> wrote:

>>> read(7, "", 128)                        =3D 0
>>> poll([{fd=3D4, events=3DPOLLIN}, {fd=3D5, events=3DPOLLIN}, {fd=3D6,  =
=20
>>> events=3DPOLLIN}, {fd=3D7, events=3DPOLLIN}, {fd=3D8, events=3DPOLLIN}]=
, 5,=20
>>> 3000)  =3D 1 ([{fd=3D7, revents=3DPOLLIN}])
So for some reason the signalfd(2) fd keeps returning nothing (which is
an error) with your self-compiled 2.6.22.20071006 kernel.
2.6.22 is supposed to work, so I will keep this bug open to see if
anybody else is affected.

I see that udevd, unlike the example in the man page, is quite
permissive in checking the results of the read.
Maybe if read(2) returns zero it should just fail.

    size =3D read(pfd[FD_SIGNAL].fd, &fdsi, sizeof(struct signalfd_siginfo)=
);
    if (size =3D=3D sizeof(struct signalfd_siginfo))
            handle_signal(udev, fdsi.ssi_signo);

--=20
ciao,
Marco

--ibTvN161/egqYuK8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkrd+8IACgkQFGfw2OHuP7HcoACdHsCGH+odn+ubWsXw1Z4w3LOE
w48AnRRHUzw96tLZhTPQer42IWcuc0ie
=k553
-----END PGP SIGNATURE-----

--ibTvN161/egqYuK8--