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

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

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