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

[christos%zoulas.com@localhost (Christos Zoulas)]

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

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Thu, 6 Apr 2017 07:16:36 -0400

 On Apr 6,  3:10am, kre%munnari.OZ.AU@localhost (Robert Elz) wrote:
 -- Subject: Re: kern/49017: vfork does not suspend all threads
 
 |  That is, in reality, what happens is that the "parent" process both stalls,
 |  and continues running (just like with setjmp()) until the terminating
 |  condition occurs (the longjmp() equiv - _exit() or exec()) - and (here
 |  I disagree with Nico) the "child" process after a vfork() can do just about
 |  anything that would be safe between a setjmp() and longjmp(), unless the
 |  operation does something which would require a proc struct alteration which
 |  is also reflected in user space (so brk() is bad).
 
 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. So one of the restrictions is "you
 can't safely return from the current stack frame... It is also
 very similar (as you said) to setjmp and longjmp as far as the
 current function frame is concerned (and register liveness) but
 the compiler takes care of that.
 
 |  What all this means to a threaded process, is that overall I'm of the opinion
 |  that only the parent thread should block (just as if the parent thread used
 |  a setjmp()) and whatever sync with other threads should be just the same for
 |  the child of the vfork() as it would have been for the thread had it not done
 |  a vfork(), with the sole exception that the child cannot use, or rely upon,
 |  anything that uses kernel process private state (and hence cannot access, or
 |  change, anything which would be protected by such a mechanism).   In process
 |  type spin locks, would be safe, sys call activated sleeping locks would not be.
 
 We agree there.
 
 |  ps: unrelated here, but the one facility missing from vfork() that would make
 |  it more useful, would be a "complete the fork" sys call, which would turn the
 |  vfork() into a fork() (dup the addr space) and be a third "wakeup the parent"
 |  operation.
 
 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.
 
 christos