[BusyBox] Bug#212764: 2 race conditions in init implementation

Vladimir N. Oleynik dzo at simtreas.ru
Mon Oct 6 10:16:46 UTC 2003


>>We blocked, not ignored SIGCHLD. If sigchld raised then signal pending
>>before unblocked. We don`t loses this signal.
> That's true, I was smoking crack here. 

?? Idioms? ;-)

> There is still a race here but
> for this reason, see below.

Its point not equivalent for below.
I think, must restore previous verion here.

>>>I have fixed the bug by replacing the wait() call in waitfor() with a
>>>waitpid() call and handle the error.
>>>- 2nd race condition
>>And same point.
> This one is not the same. You unblocked the signal before the second
> fork(). It is not a blocking/unblocking problem here. 
> There is a race between the call to signal() and the signal handler
> (child_handler()). If the handler is called before signal(), the code
> will loop forever since waitpid will return -1 with errno == ECHILD.

Ah! You compared with verions have child_handler()? :-0
We remove child handler ~ 15 day ago.

> It is the same for the first race. If the handler is called before
> wait(), wait() will block.

wait MUST block!

> BTW, the SIGCHLD handler reaps all zombies, how can you expect that the
> unchecked calls to wait() and waitpid() will succeed on SMP ?

This code point must have wait(), not waitpid()

>>I recomended restore previous version from CVS before realy
>>demonstrating problem.
> I recommend you leave it in the CVS. 

You have found problems in yours patch for this letter!

> Testing return codes is good

This code is difficult for testing for correctness.

Previous code may be have problem, I look Jean have point for demonstrate.
But your patch is bad!


More information about the busybox mailing list