linux-kernel - Re: [PATCH] fix handling of SIGCHILD from reaped child

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 21 Feb 2007 09:51:51 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	oleg@...sign.ru, linux-kernel@...r.kernel.org, mingo@...e.hu,
	akpm@...ux-foundation.org, mtk-manpages@....net
Subject: Re: [PATCH] fix handling of SIGCHILD from reaped child

On Tue, 20 Feb 2007 15:10:07 -0800 (PST)
Roland McGrath <roland@...hat.com> wrote:

> I'm usually the stickler for anal POSIX compliance, but this is one thing
> that I did notice a while ago, realized Linux had never done it, and
> decided I didn't care.
> 
Okay, I don't think this is a big trouble.

> This is one of those parts of the standard that was originally written in a
> single-threaded process frame of mind, and was never amended or clarified
> later when multi-threaded semantics got well-specified in the standard.
> 
> It's clear what the requirement is trying to achieve.  It lets you have a
> SIGCHLD signal handler that calls wait, and be sure its call never blocks,
> as long as you block SIGCHLD while making any other wait calls.  But Linux
> has never done this even for single-threaded processes, so existing
> application code already has to cope with the race.  (Anyway, this
> guarantee is not all that helpful if you have more than one child and so
> might be running the handler once after SIGCHLD was generated more than
> once.  You can't just use WNOHANG in your handler because you aren't
> actually guaranteed that the zombie is ready already when you get the SIGCHLD.)
> 
> This guarantee is not of any use when there might be other threads with
> SIGCHLD unblocked or other threads that call wait* functions (calls that
> draw from the same pool of PIDs anyway).  There can always be another
> thread that just dequeued the SIGCHLD but hasn't gotten into its handler
> yet, so clearing the pending SIGCHLD doesn't really cover it.
> 
> Unhelpful as it is the multithreaded context, I think it's clear that the
> standard's wording means "when SIGCHLD is blocked by the thread calling
> wait", but in fact as to being a guarantee it's only meaningful when
> SIGCHLD is blocked by all threads.  The mention of blocking the signal is
> only there to remind you that well-defined semantics about a "pending"
> signal only ever apply when the signal is blocked.  If any thread has it
> unblocked, then "pending" is an ephemeral condition not necessarily
> observable at all--as soon as you could say it's pending, some such thread
> might be handling it.
> 
> The "if there is another child available" test is rather ugly to do
> correctly now.  It would be less so if the children list moved into
> signal_struct and was just shared directly.  The most "correct" it can get
> is still not all that useful in a multithreaded context.  So I'm pretty
> ambivalent about bothering with this.
> 
Hmm, okay. It seems a good workaround to say "please use WNOHANG always in
your SIGCHLD handler's wait*() call" 

My only concerns is that LSB people say wait/waitpid meets SUSv3. 

Thanks,
-Kame

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/