Re: GNUnet News: vfork and the signal race
Hallo! On Sat, 26 Nov 2011 15:53:45 +0100, Christian Grothoff wrote: > Thank you Thomas for your suggestion. For our purposes, this is a > better (certainly more portable) solution that does always work. Great that Thomas Bushnell could help finding a yet-better solution for the original problem. Always remember to ask your fellow Hurd folks for such OS level issues, eh? ;-) Grüße, Thomas pgpmvU5iOzxqt.pgp Description: PGP signature
Re: GNUnet News: vfork and the signal race
Thank you Thomas for your suggestion. For our purposes, this is a better (certainly more portable) solution that does always work. Happy hacking, Christian On 11/26/2011 02:43 AM, Thomas Bushnell, BSG wrote: Oh, and in the case you describe there: The hypervisor at start creates a global variable hypervisor_pid, initialized from getpid(). The signal handler in the hypervisor then does this: if getpid() == hypervisor_pid kill_all_children_and_exit(); else exit(); In this way, if the child is between fork and exec when the parent gets its kill, and then it tries to kill the child, and the kill happens before the child execs (the problematic case you describe), then the child simply enters the hypervisor's signal handler, notices that it's not the hypervisor, and exits. Thomas On Fri, Nov 25, 2011 at 4:09 PM, Christian Grothoff mailto:christ...@grothoff.org>> wrote: On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote: Programs which depend on the special suspend-the-parent behavior of vfork were always regarded as buggy... So relying on the well-documented behavior of a system call is a bug? Did you even read about the scenario I described at https://gnunet.org/vfork ? Before writing this, I looked around for existing information on vfork, but I didn't find anyone making a good argument (or even the claim) that relying on 'suspend-the-parent' was per-se buggy. (Naturally, the result would be non-portable for systems where fork==vfork, but then maybe implementing vfork as fork is the bug? ;-)) Happy hacking Christian
Re: GNUnet News: vfork and the signal race
Samuel Thibault, le Sat 26 Nov 2011 15:14:11 +0100, a écrit : > Richard Braun, le Sat 26 Nov 2011 15:12:50 +0100, a écrit : > > On Sat, Nov 26, 2011 at 11:35:29AM +0100, Samuel Thibault wrote: > > > > (Naturally, the result would be non-portable for systems where > > > > fork==vfork, > > > > but then maybe implementing vfork as fork is the bug? ;-)) > > > > > > It's what the norm says. > > > > I think you meant the norm explicitely says vfork can be implemented as > > fork. > > Yes, which is sufficient for what you said. I meant what *he* said. Samuel
Re: GNUnet News: vfork and the signal race
Richard Braun, le Sat 26 Nov 2011 15:12:50 +0100, a écrit : > On Sat, Nov 26, 2011 at 11:35:29AM +0100, Samuel Thibault wrote: > > > (Naturally, the result would be non-portable for systems where > > > fork==vfork, > > > but then maybe implementing vfork as fork is the bug? ;-)) > > > > It's what the norm says. > > I think you meant the norm explicitely says vfork can be implemented as > fork. Yes, which is sufficient for what you said. > > Now, about the problem you mention on the webpage, isn't it possible to > > use a semaphore to tell the hypervisor when the "just-forked" process > > has changed its signal handler for something that is fine with SIGTERM? > > Or use a signal back (IIRC Xorg does this). That would implement the > > "make father wait" in a portable way. > > How about blocking signals until the child is actually able to handle > SIGTERM correctly ? POSIX clearly states signal masks are inherited on > forks. AIUI, this case doesn't need the parent to wait, only to avoid > the kill/exec race. Indeed. Samuel
Re: GNUnet News: vfork and the signal race
On Sat, Nov 26, 2011 at 11:35:29AM +0100, Samuel Thibault wrote: > > (Naturally, the result would be non-portable for systems where fork==vfork, > > but then maybe implementing vfork as fork is the bug? ;-)) > > It's what the norm says. I think you meant the norm explicitely says vfork can be implemented as fork. > Now, about the problem you mention on the webpage, isn't it possible to > use a semaphore to tell the hypervisor when the "just-forked" process > has changed its signal handler for something that is fine with SIGTERM? > Or use a signal back (IIRC Xorg does this). That would implement the > "make father wait" in a portable way. How about blocking signals until the child is actually able to handle SIGTERM correctly ? POSIX clearly states signal masks are inherited on forks. AIUI, this case doesn't need the parent to wait, only to avoid the kill/exec race. -- Richard Braun
Re: GNUnet News: vfork and the signal race
Christian Grothoff, le Sat 26 Nov 2011 01:09:59 +0100, a écrit : > On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote: > >Programs which depend on the special suspend-the-parent behavior of > >vfork were always regarded as buggy... > > So relying on the well-documented behavior of a system call is a bug? A documentation is not a norm. The norm only says that it "shall be equivalent to fork(), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec family of functions." Relying on some OS documentation makes you out of portability, it's the norm that matters for portability. Posix has actually even just dropped the function from its standard, so using vfork is now not even standard according to POSIX 2008. > Did > you even read about the scenario I described at > https://gnunet.org/vfork ? Before writing this, I looked around for existing > information on vfork, but I didn't find anyone making a good argument (or > even the claim) that relying on 'suspend-the-parent' was per-se buggy. Nothing in the POSIX norm says that the parent is suspended. > (Naturally, the result would be non-portable for systems where fork==vfork, > but then maybe implementing vfork as fork is the bug? ;-)) It's what the norm says. Now, about the problem you mention on the webpage, isn't it possible to use a semaphore to tell the hypervisor when the "just-forked" process has changed its signal handler for something that is fine with SIGTERM? Or use a signal back (IIRC Xorg does this). That would implement the "make father wait" in a portable way. Samuel
Re: GNUnet News: vfork and the signal race
On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote: Programs which depend on the special suspend-the-parent behavior of vfork were always regarded as buggy... So relying on the well-documented behavior of a system call is a bug? Did you even read about the scenario I described at https://gnunet.org/vfork ? Before writing this, I looked around for existing information on vfork, but I didn't find anyone making a good argument (or even the claim) that relying on 'suspend-the-parent' was per-se buggy. (Naturally, the result would be non-portable for systems where fork==vfork, but then maybe implementing vfork as fork is the bug? ;-)) Happy hacking Christian
Re: GNUnet News: vfork and the signal race
Oh, and in the case you describe there: The hypervisor at start creates a global variable hypervisor_pid, initialized from getpid(). The signal handler in the hypervisor then does this: if getpid() == hypervisor_pid kill_all_children_and_exit(); else exit(); In this way, if the child is between fork and exec when the parent gets its kill, and then it tries to kill the child, and the kill happens before the child execs (the problematic case you describe), then the child simply enters the hypervisor's signal handler, notices that it's not the hypervisor, and exits. Thomas On Fri, Nov 25, 2011 at 4:09 PM, Christian Grothoff wrote: > On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote: > >> Programs which depend on the special suspend-the-parent behavior of >> vfork were always regarded as buggy... >> > > So relying on the well-documented behavior of a system call is a bug? Did > you even read about the scenario I described at > https://gnunet.org/vfork ? Before writing this, I looked around for > existing information on vfork, but I didn't find anyone making a good > argument (or even the claim) that relying on 'suspend-the-parent' was > per-se buggy. (Naturally, the result would be non-portable for systems > where fork==vfork, but then maybe implementing vfork as fork is the bug? > ;-)) > > Happy hacking > > Christian >
Re: GNUnet News: vfork and the signal race
The original BSD man page warned that the behavior should not be relied on. Thomas On Nov 25, 2011 4:10 PM, "Christian Grothoff" wrote: > On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote: > >> Programs which depend on the special suspend-the-parent behavior of >> vfork were always regarded as buggy... >> > > So relying on the well-documented behavior of a system call is a bug? Did > you even read about the scenario I described at > https://gnunet.org/vfork ? Before writing this, I looked around for > existing information on vfork, but I didn't find anyone making a good > argument (or even the claim) that relying on 'suspend-the-parent' was > per-se buggy. (Naturally, the result would be non-portable for systems > where fork==vfork, but then maybe implementing vfork as fork is the bug? > ;-)) > > Happy hacking > > Christian >
Re: GNUnet News: vfork and the signal race
Programs which depend on the special suspend-the-parent behavior of vfork
were always regarded as buggy...
Thomas
On Fri, Nov 25, 2011 at 7:42 AM, Thomas Schwinge wrote:
> Hallo!
>
> On Thu, 24 Nov 2011 15:59:55 -, Planet GNU
> wrote:
> > Many articles uniformly claim that using vfork should be
> > [avoided][1] and that the only difference between vfork and fork is (or
> > used-to-be) [performance][2] and that thus vfork is [obsolte][3]. Here, I
> > wanted to document a technical case where vfork is actually required and
> > where using vfork instead of fork (or operating system implementors
> > implementing vfork as an alias for fork) causes a hard-to-find data race.
> > [...]
> > URL: https://gnunet.org/vfork
>
> Rather ``using *fork* instead of *vfork*'', I assume?
>
>
> Just for the record, the Hurd doesn't have a vfork implementation, and
> we're thus using glibc's default POSIX vfork implementation:
>
>/* If we don't have vfork, fork is close enough. */
>
>__pid_t
>__vfork (void)
>{
> return __fork ();
>}
>
> I wonder how clumsy it would get to add vfork's ``parent blocks until the
> child calls _exit or exec'' functionality.
>
>
> Grüße,
> Thomas
>
Re: GNUnet News: vfork and the signal race
Hallo!
On Thu, 24 Nov 2011 15:59:55 -, Planet GNU wrote:
> Many articles uniformly claim that using vfork should be
> [avoided][1] and that the only difference between vfork and fork is (or
> used-to-be) [performance][2] and that thus vfork is [obsolte][3]. Here, I
> wanted to document a technical case where vfork is actually required and
> where using vfork instead of fork (or operating system implementors
> implementing vfork as an alias for fork) causes a hard-to-find data race.
> [...]
> URL: https://gnunet.org/vfork
Rather ``using *fork* instead of *vfork*'', I assume?
Just for the record, the Hurd doesn't have a vfork implementation, and
we're thus using glibc's default POSIX vfork implementation:
/* If we don't have vfork, fork is close enough. */
__pid_t
__vfork (void)
{
return __fork ();
}
I wonder how clumsy it would get to add vfork's ``parent blocks until the
child calls _exit or exec'' functionality.
Grüße,
Thomas
pgpYoE44JKDua.pgp
Description: PGP signature
