1 .\" Copyright (c) 1999 Andries Brouwer (aeb@cwi.nl), 1 Nov 1999
2 .\" and Copyright 2006, 2012, 2017 Michael Kerrisk <mtk.manpages@gmail.com>
4 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
6 .\" 1999-11-10: Merged text taken from the page contributed by
7 .\" Reed H. Petty (rhp@draper.net)
9 .TH VFORK 2 2021-03-22 "Linux man-pages (unreleased)" "Linux Programmer's Manual"
11 vfork \- create a child process and block parent
14 .RI ( libc ", " \-lc )
17 .B #include <unistd.h>
23 Feature Test Macro Requirements for glibc (see
24 .BR feature_test_macros (7)):
30 (_XOPEN_SOURCE >= 500) && ! (_POSIX_C_SOURCE >= 200809L)
31 || /* Since glibc 2.19: */ _DEFAULT_SOURCE
32 || /* Glibc <= 2.19: */ _BSD_SOURCE
34 _BSD_SOURCE || _XOPEN_SOURCE >= 500
35 .\" || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
38 .SS Standard description
42 function has the same effect as
44 except that the behavior is undefined if the process created by
46 either modifies any data other than a variable of type
48 used to store the return value from
50 or returns from the function in which
52 was called, or calls any other function before successfully calling
61 creates a child process of the calling process.
62 For details and return value and errors, see
68 It is used to create new processes without copying the page tables of
70 It may be useful in performance-sensitive applications
71 where a child is created which then immediately issues an
77 in that the calling thread is suspended until the child terminates
81 or abnormally, after delivery of a fatal signal),
84 Until that point, the child shares all memory with its parent,
86 The child must not return from the current function or call
88 (which would have the effect of calling exit handlers
89 established by the parent process and flushing the parent's
91 buffers), but may call
96 the child process created by
98 inherits copies of various of the caller's process attributes
99 (e.g., file descriptors, signal dispositions, and current working directory);
102 call differs only in the treatment of the virtual address space,
105 Signals sent to the parent
106 arrive after the child releases the parent's memory
107 (i.e., after the child terminates
110 .SS Historic description
113 is implemented using copy-on-write pages, so the only penalty incurred by
115 is the time and memory required to duplicate the parent's page tables,
116 and to create a unique task structure for the child.
117 However, in the bad old days a
119 would require making a complete copy of the caller's data space,
120 often needlessly, since usually immediately afterward an
123 Thus, for greater efficiency, BSD introduced the
125 system call, which did not fully copy the address space of
126 the parent process, but borrowed the parent's memory and thread
127 of control until a call to
130 The parent process was suspended while the
131 child was using its resources.
134 was tricky: for example, not modifying data
135 in the parent process depended on knowing which variables were
138 4.3BSD; POSIX.1-2001 (but marked OBSOLETE).
139 POSIX.1-2008 removes the specification of
142 The requirements put on
144 by the standards are weaker than those put on
146 so an implementation where the two are synonymous is compliant.
147 In particular, the programmer cannot rely on the parent
148 remaining blocked until the child either terminates or calls
150 and cannot rely on any specific behavior with respect to shared memory.
151 .\" In AIXv3.1 vfork is equivalent to fork.
153 Some consider the semantics of
155 to be an architectural blemish, and the 4.2BSD man page stated:
156 "This system call will be eliminated when proper system sharing mechanisms
158 Users should not depend on the memory sharing semantics of
160 as it will, in that case, be made synonymous to
163 However, even though modern memory management hardware
164 has decreased the performance difference between
168 there are various reasons why Linux and other systems have retained
171 Some performance-critical applications require the small performance
172 advantage conferred by
176 can be implemented on systems that lack a memory-management unit (MMU), but
178 can't be implemented on such systems.
179 (POSIX.1-2008 removed
181 from the standard; the POSIX rationale for the
183 function notes that that function,
184 which provides functionality equivalent to
185 .BR fork (2)+ exec (3),
186 is designed to be implementable on systems that lack an MMU.)
187 .\" http://stackoverflow.com/questions/4259629/what-is-the-difference-between-fork-and-vfork
188 .\" http://developers.sun.com/solaris/articles/subprocess/subprocess.html
189 .\" http://mailman.uclinux.org/pipermail/uclinux-dev/2009-April/000684.html
192 On systems where memory is constrained,
194 avoids the need to temporarily commit memory (see the description of
195 .I /proc/sys/vm/overcommit_memory
198 in order to execute a new program.
199 (This can be especially beneficial where a large parent process wishes
200 to execute a small helper program in a child process.)
203 in this scenario requires either committing an amount of memory equal
204 to the size of the parent process (if strict overcommitting is in force)
205 or overcommitting memory with the risk that a process is terminated
206 by the out-of-memory (OOM) killer.
209 The child process should take care not to modify the memory in unintended ways,
210 since such changes will be seen by the parent process once
211 the child terminates or executes another program.
212 In this regard, signal handlers can be especially problematic:
213 if a signal handler that is invoked in the child of
215 changes memory, those changes may result in an inconsistent process state
216 from the perspective of the parent process
217 (e.g., memory changes would be visible in the parent,
218 but changes to the state of open file descriptors would not be visible).
222 is called in a multithreaded process,
223 only the calling thread is suspended until the child terminates
224 or executes a new program.
225 This means that the child is sharing an address space with other running code.
226 This can be dangerous if another thread in the parent process
227 changes credentials (using
230 since there are now two processes with different privilege levels
231 running in the same address space.
232 As an example of the dangers,
233 suppose that a multithreaded program running as root creates a child using
237 a thread in the parent process drops the process to an unprivileged user
238 in order to run some untrusted code
239 (e.g., perhaps via plug-in opened with
241 In this case, attacks are possible where the parent process uses
243 to map in code that will be executed by the privileged child process.
246 Fork handlers established using
247 .BR pthread_atfork (3)
248 are not called when a multithreaded program employing
249 the NPTL threading library calls
251 Fork handlers are called in this case in a program using the
252 LinuxThreads threading library.
255 for a description of Linux threading libraries.)
259 is equivalent to calling
267 CLONE_VM | CLONE_VFORK | SIGCHLD
273 system call appeared in 3.0BSD.
274 .\" In the release notes for 4.2BSD Sam Leffler wrote: `vfork: Is still
275 .\" present, but definitely on its way out'.
276 In 4.4BSD it was made synonymous to
278 but NetBSD introduced it again;
280 .UR http://www.netbsd.org\:/Documentation\:/kernel\:/vfork.html
282 In Linux, it has been equivalent to
284 until 2.2.0-pre6 or so.
285 Since 2.2.0-pre9 (on i386, somewhat later on
286 other architectures) it is an independent system call.
287 Support was added in glibc 2.0.112.
289 Details of the signal handling are obscure and differ between systems.
290 The BSD man page states:
291 "To avoid a possible deadlock situation, processes that are children
298 signals; rather, output or
300 are allowed and input attempts result in an end-of-file indication."
302 .\" As far as I can tell, the following is not true in 2.6.19:
303 .\" Currently (Linux 2.3.25),
307 .\" and requires a kernel patch.