fork() marks non-shared pages copy-on-write, instead of copying them
immediately; they won't take any additional VM unless they are written to.
At most this should be one stack page and possibly one data page; otherwise,
you've also violated the restrictions on vfork() so you will lose anyway
(the child may succeed, but the parent's memory will be corrupted).
Basically, any situation which is a no-win for copy-on-write fork() will
lose in a different way for vfork(), and neither one is likely to be easily
recoverable. In fact, the vfork() version will probably lose worse because
the kernel can't do *anything* about it: the corruption is entirely
user-space. Whereas if vfork() will succeed, so will fork().
With respect to your examples: when the child exec()s, the copied pages are
immediately reused. If they aren't available for the fork() to use, they
aren't going to be available for the exec() either, so you lose regardless.
The only difference is that the failure happens at fork() time instead of at
exec() time --- and vfork() assumes the exec() will succeed, so the parent's
stack will very probably be trashed by the vfork()ed child in the aftermath
of the failed exec(). (Not to mention trashing due to anything that happens
that can't be blocked by _exit(), unless the failing child's response is to
SIGKILL itself --- if it sends a signal for which a handler exists, again
the parent will be trashed.)
-- brandon s. allbery os/2,linux,solaris,perl allbery@kf8nh.apk.net system administrator kthkrb,heimdal,gnome,rt allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering kf8nh We are Linux. Resistance is an indication that you missed the point.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/