Re: kern/49017: vfork does not suspend all threads

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/49017; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: christos%zoulas.com@localhost (Christos Zoulas)
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Thu, 06 Apr 2017 21:15:08 +0700

     Date:        Thu, 6 Apr 2017 07:16:36 -0400
     From:        christos%zoulas.com@localhost (Christos Zoulas)
     Message-ID:  <20170406111636.92DF217FDA8%rebar.astron.com@localhost>
 
   | It is much more restricted than that. For example if the child
   | continues and returns from its current stack frame to other higher
   | up frames, it makes changes to them so when the parent resumes it
   | finds an inconsistent state.
 
 Just the same as setjmp() ... no question but that there are restrictions
 after a vfork(), but they're not as strict (not nearly as strict) as async
 signal safe (which needs to be prepared to execute with the "parent" in
 any state at all - here we know the parent is blocked in vfork() so is
 not currently doing anything.)
 
   | |  would be a "complete the fork" sys call, which would turn the
   | |  vfork() into a fork()
 
   | The difficulty with that is that the child needs to know that it has been
   | vforked instead of forked... So the child needs code to handle both cases
   | in general which is annoying.
 
 Huh?   The code is
 
 	if (vfork() == 0) {
 		/* here I am the child */
 	}
 
 How does the child possibly not know it has been vforked?   What I
 suggested (as some kind of dream, not a serious proposal, or not without
 trying it anyway) would be to allow
 
 	if (vfork() == 0) {
 		/* child, with parent blocked and shared mem */
 		
 		/* code here, probably tests to decide what next */
 
 		vfork_into_fork();
 		/* now parent is unblocked, and child has its own addr space */
 	}
 
 (and no, I don't think "vfork_into_fork()" is a sensible name...)
 
 
 Joerg Sonnenberger <joerg%bec.de@localhost> said:
   | The problem is that many of the functions outside the "async signal safe"
   | category are exactly allowed to such things.
 
 Sure, but there are plenty that are, much more than what is safe in a
 signal handler.
 
 There's no question but that using vfork() requires some care (or very
 simple operations) but that's not a reason to restrict it more than what
 it already is.
 
 For the PR that started all this, my suggestion would be to simply fix the
 man page, and close it.
 
 kre