linux-kernel - Re: parent process behaviour to signal after vfork()

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <53383.1225345110@turing-police.cc.vt.edu>
Date:	Thu, 30 Oct 2008 01:38:30 -0400
From:	Valdis.Kletnieks@...edu
To:	Michael Kerrisk <mtk.manpages@...il.com>
Cc:	Halesh S <halesh.s@...ia.com>, linux-kernel@...r.kernel.org
Subject: Re: parent process behaviour to signal after vfork()

On Wed, 29 Oct 2008 08:17:36 CDT, Michael Kerrisk said:

> diff --git a/man2/vfork.2 b/man2/vfork.2
> index 55044ad..8a7ed50 100644
> --- a/man2/vfork.2
> +++ b/man2/vfork.2
> @@ -94,7 +94,10 @@ but may call
>  .PP
>  Signal handlers are inherited, but not shared.
>  Signals to the parent
> -arrive after the child releases the parent's memory.
> +arrive after the child releases the parent's memory (i.e., after the child calls
> +.BR _exit (2)
> +or
> +.BR execve (2)).

OK, I'll bite - when is the parent's memory released if the child doesn't
depart by calling _exit() or execve(), but manages to get killed by an
unhandled signal or the OOM killer or similar?

(That's the generic problem with adding itemized lists to an explanation - it's
rarely clear if the list is an exhaustive list, or a non-complete list of
examples.  Note how often we have flame wars regarding which EQUUX should be
returned in a corner case that hinge on whether Posix says "Only FOO, BAR,
and BAZ can be returned" or "FOO, BAR, BAZ are among the errors that can be
returned")

Content of type "application/pgp-signature" skipped