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]

Date:	Thu, 30 Oct 2008 08:24:44 -0500
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	Valdis.Kletnieks@...edu
Cc:	"Halesh S" <halesh.s@...ia.com>, linux-kernel@...r.kernel.org
Subject: Re: parent process behaviour to signal after vfork()

Hi Valdis,

On Thu, Oct 30, 2008 at 12:38 AM,  <Valdis.Kletnieks@...edu> wrote:
> 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?

Yes, thanks for catching that.  The wording really should say, until
the child does execve(2) or it terminates.

> (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")

I agree that this is sometime true, but examples need to be looked at
on a case-by-case basis.  Sometimes using deliberately vague language
is appropriate.  But sometimes, the solution is just better, more
precise language, and I think that's the case here.  For
man-pages-3.13, I applied the patch below.

Cheers,

Michael
--
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/