.\" Copyright (c) 1999 Andries Brouwer (aeb@cwi.nl), 1 Nov 1999
+.\" and Copyright 2006, 2012, 2017 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" %%%LICENSE_START(VERBATIM)
.\" Permission is granted to make and distribute verbatim copies of this
.\" 1999-11-10: Merged text taken from the page contributed by
.\" Reed H. Petty (rhp@draper.net)
.\"
-.TH VFORK 2 2012-08-05 "Linux" "Linux Programmer's Manual"
+.TH VFORK 2 2017-09-15 "Linux" "Linux Programmer's Manual"
.SH NAME
vfork \- create a child process and block parent
.SH SYNOPSIS
.B #include <sys/types.h>
.br
.B #include <unistd.h>
-.sp
+.PP
.B pid_t vfork(void);
-.sp
+.PP
.in -4n
Feature Test Macro Requirements for glibc (see
.BR feature_test_macros (7)):
.in
-.sp
+.PP
.BR vfork ():
.ad l
.RS 4
.TP 4
Since glibc 2.12:
.nf
-_BSD_SOURCE ||
- (_XOPEN_SOURCE\ >=\ 500 ||
- _XOPEN_SOURCE\ &&\ _XOPEN_SOURCE_EXTENDED) &&
- ! (_POSIX_C_SOURCE\ >=\ 200809L)
+(_XOPEN_SOURCE\ >=\ 500) && ! (_POSIX_C_SOURCE\ >=\ 200809L)
+ || /* Since glibc 2.19: */ _DEFAULT_SOURCE
+ || /* Glibc versions <= 2.19: */ _BSD_SOURCE
.TP 4
.fi
Before glibc 2.12:
-_BSD_SOURCE || _XOPEN_SOURCE\ >=\ 500 ||
-_XOPEN_SOURCE\ &&\ _XOPEN_SOURCE_EXTENDED
+_BSD_SOURCE || _XOPEN_SOURCE\ >=\ 500
+.\" || _XOPEN_SOURCE\ &&\ _XOPEN_SOURCE_EXTENDED
.PD
.RE
.ad b
Until that point, the child shares all memory with its parent,
including the stack.
The child must not return from the current function or call
-.BR exit (3),
-but may call
+.BR exit (3)
+(which would have the effect of calling exit handlers
+established by the parent process and flushing the parent's
+.BR stdio (3)
+buffers), but may call
.BR _exit (2).
-
+.PP
As with
.BR fork (2),
the child process created by
.BR vfork ()
call differs only in the treatment of the virtual address space,
as described above.
-
+.PP
Signals sent to the parent
arrive after the child releases the parent's memory
(i.e., after the child terminates
4.3BSD; POSIX.1-2001 (but marked OBSOLETE).
POSIX.1-2008 removes the specification of
.BR vfork ().
-
+.PP
The requirements put on
.BR vfork ()
by the standards are weaker than those put on
.\" http://stackoverflow.com/questions/4259629/what-is-the-difference-between-fork-and-vfork
.\" http://developers.sun.com/solaris/articles/subprocess/subprocess.html
.\" http://mailman.uclinux.org/pipermail/uclinux-dev/2009-April/000684.html
+.\"
+.IP *
+On systems where memory is constrained,
+.BR vfork ()
+avoids the need to temporarily commit memory (see the description of
+.IR /proc/sys/vm/overcommit_memory
+in
+.BR proc (5))
+in order to execute a new program.
+(This can be especially beneficial where a large parent process wishes
+to execute a small helper program in a child process.)
+By contrast, using
+.BR fork (2)
+in this scenario requires either committing an amount of memory equal
+to the size of the parent process (if strict overcommitting is in force)
+or overcommitting memory with the risk that a process is terminated
+by the out-of-memory (OOM) killer.
+.\"
+.SS Caveats
+The child process should take care not to modify the memory in unintended ways,
+since such changes will be seen by the parent process once
+the child terminates or executes another program.
+In this regard, signal handlers can be especially problematic:
+if a signal handler that is invoked in the child of
+.BR vfork ()
+changes memory, those changes may result in an inconsistent process state
+from the perspective of the parent process
+(e.g., memory changes would be visible in the parent,
+but changes to the state of open file descriptors would not be visible).
+.PP
+When
+.BR vfork ()
+is called in a multithreaded process,
+only the calling thread is suspended until the child terminates
+or executes a new program.
+This means that the child is sharing an address space with other running code.
+This can be dangerous if another thread in the parent process
+changes credentials (using
+.BR setuid (2)
+or similar),
+since there are now two processes with different privilege levels
+running in the same address space.
+As an example of the dangers,
+suppose that a multithreaded program running as root creates a child using
+.BR vfork ().
+After the
+.BR vfork (),
+a thread in the parent process drops the process to an unprivileged user
+in order to run some untrusted code
+(e.g., perhaps via plug-in opened with
+.BR dlopen (3)).
+In this case, attacks are possible where the parent process uses
+.BR mmap (2)
+to map in code that will be executed by the privileged child process.
+.\"
.SS Linux notes
Fork handlers established using
.BR pthread_atfork (3)
(See
.BR pthreads (7)
for a description of Linux threading libraries.)
-
+.PP
A call to
.BR vfork ()
is equivalent to calling
with
.I flags
specified as:
-
+.PP
CLONE_VM | CLONE_VFORK | SIGCHLD
.SS History
The
.\" present, but definitely on its way out'.
In 4.4BSD it was made synonymous to
.BR fork (2)
-but NetBSD introduced it again,
-cf.
+but NetBSD introduced it again;
+see
.UR http://www.netbsd.org\:/Documentation\:/kernel\:/vfork.html
.UE .
In Linux, it has been equivalent to
.SH SEE ALSO
.BR clone (2),
.BR execve (2),
+.BR _exit (2),
.BR fork (2),
.BR unshare (2),
.BR wait (2)
projects / thirdparty / man-pages.git / blobdiff