Re: Bug#551743: udevd spawns numerous processes and eats up almost

Re: Bug#551743: udevd spawns numerous processes and eats up almost

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

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

>>> read(7, "", 128)                        = 0
>>> 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=7, revents=POLLIN}])
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 = read(pfd[FD_SIGNAL].fd, &fdsi, sizeof(struct signalfd_siginfo));
    if (size == sizeof(struct signalfd_siginfo))
            handle_signal(udev, fdsi.ssi_signo);

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Bug#551743: udevd spawns numerous processes and eats up almost

[Alan Jenkins]

On 10/20/09, Marco d'Itri <md@linux.it> wrote:
> On Oct 20, Torsten Crass <torsten.crass@eBiology.de> wrote:
>
>>>> read(7, "", 128)                        = 0
>>>> 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=7, revents=POLLIN}])
> 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 = read(pfd[FD_SIGNAL].fd, &fdsi, sizeof(struct signalfd_siginfo));
>     if (size = sizeof(struct signalfd_siginfo))
>             handle_signal(udev, fdsi.ssi_signo);
>

Sounds good to me.  A zero return from read should always mean EOF.
Whatever this means for a signalfd, it's not "ignore this result and
try again".  The manpage seems to exclude it anyway.

"If  none  of  the  signals  in mask is pending for the process, then
the read(2) either blocks  until one of the signals in mask is
generated for the process, or fails with the error  EAGAIN if the file
descriptor has been made non-blocking."

Alan