[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1802051936460.25773@monopod.intra.ispras.ru>
Date: Mon, 5 Feb 2018 20:07:44 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] re-fix child reaping in wordexp
On Mon, 5 Feb 2018, Rich Felker wrote:
> > In general retrying waitpid on EINTR is not robust in case pid reuse is
> > possible, but fixing that requires changing waitpid call sites to only
> > do that with signals blocked (where that's not already the case).
>
> I don't follow this. Unless there's a bug in the kernel, this should
> not be functionally different from SA_RESTART. A return with EINTR
> means the child was not reaped.
The problem I had in mind is that you don't know if a signal handler or
another thread had (yes, incorrectly) already reaped that child when you
are about to retry waitpid.
With signals blocked, you issue just one waitpid, and you need very rapid
pid reuse to happen, after someone successfully reaps your child
even before you enter waitpid.
Of course this is a bit moot since the other thread/sighandler shouldn't
be issuing wildcard waits in the first place, and if rapid pid reuse
does not happen you safely leave the retry loop with ECHILD. But this is
why I said "not robust" rather than "incorrect".
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
