man2/vfork.2

   1 .\" Copyright (c) 1999 Andries Brouwer (aeb@cwi.nl), 1 Nov 1999
   2 .\" and Copyright 2006, 2012, 2017 Michael Kerrisk <mtk.manpages@gmail.com>
   3 .\"
   4 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
   5 .\"
   6 .\" 1999-11-10: Merged text taken from the page contributed by
   7 .\" Reed H. Petty (rhp@draper.net)
   8 .\"
   9 .TH vfork 2 (date) "Linux man-pages (unreleased)"
  10 .SH NAME
  11 vfork \- create a child process and block parent
  12 .SH LIBRARY
  13 Standard C library
  14 .RI ( libc ", " \-lc )
  15 .SH SYNOPSIS
  16 .nf
  17 .B #include <unistd.h>
  18 .P
  19 .B pid_t vfork(void);
  20 .fi
  21 .P
  22 .RS -4
  23 Feature Test Macro Requirements for glibc (see
  24 .BR feature_test_macros (7)):
  25 .RE
  26 .P
  27 .BR vfork ():
  28 .nf
  29     Since glibc 2.12:
  30         (_XOPEN_SOURCE >= 500) && ! (_POSIX_C_SOURCE >= 200809L)
  31             || /* Since glibc 2.19: */ _DEFAULT_SOURCE
  32             || /* glibc <= 2.19: */ _BSD_SOURCE
  33     Before glibc 2.12:
  34         _BSD_SOURCE || _XOPEN_SOURCE >= 500
  35 .\"     || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
  36 .fi
  37 .SH DESCRIPTION
  38 .SS Standard description
  39 (From POSIX.1)
  40 The
  41 .BR vfork ()
  42 function has the same effect as
  43 .BR fork (2),
  44 except that the behavior is undefined if the process created by
  45 .BR vfork ()
  46 either modifies any data other than a variable of type
  47 .I pid_t
  48 used to store the return value from
  49 .BR vfork (),
  50 or returns from the function in which
  51 .BR vfork ()
  52 was called, or calls any other function before successfully calling
  53 .BR _exit (2)
  54 or one of the
  55 .BR exec (3)
  56 family of functions.
  57 .SS Linux description
  58 .BR vfork (),
  59 just like
  60 .BR fork (2),
  61 creates a child process of the calling process.
  62 For details and return value and errors, see
  63 .BR fork (2).
  64 .P
  65 .BR vfork ()
  66 is a special case of
  67 .BR clone (2).
  68 It is used to create new processes without copying the page tables of
  69 the parent process.
  70 It may be useful in performance-sensitive applications
  71 where a child is created which then immediately issues an
  72 .BR execve (2).
  73 .P
  74 .BR vfork ()
  75 differs from
  76 .BR fork (2)
  77 in that the calling thread is suspended until the child terminates
  78 (either normally,
  79 by calling
  80 .BR _exit (2),
  81 or abnormally, after delivery of a fatal signal),
  82 or it makes a call to
  83 .BR execve (2).
  84 Until that point, the child shares all memory with its parent,
  85 including the stack.
  86 The child must not return from the current function or call
  87 .BR exit (3)
  88 (which would have the effect of calling exit handlers
  89 established by the parent process and flushing the parent's
  90 .BR stdio (3)
  91 buffers), but may call
  92 .BR _exit (2).
  93 .P
  94 As with
  95 .BR fork (2),
  96 the child process created by
  97 .BR vfork ()
  98 inherits copies of various of the caller's process attributes
  99 (e.g., file descriptors, signal dispositions, and current working directory);
 100 the
 101 .BR vfork ()
 102 call differs only in the treatment of the virtual address space,
 103 as described above.
 104 .P
 105 Signals sent to the parent
 106 arrive after the child releases the parent's memory
 107 (i.e., after the child terminates
 108 or calls
 109 .BR execve (2)).
 110 .SS Historic description
 111 Under Linux,
 112 .BR fork (2)
 113 is implemented using copy-on-write pages, so the only penalty incurred by
 114 .BR fork (2)
 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
 118 .BR fork (2)
 119 would require making a complete copy of the caller's data space,
 120 often needlessly, since usually immediately afterward an
 121 .BR exec (3)
 122 is done.
 123 Thus, for greater efficiency, BSD introduced the
 124 .BR vfork ()
 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
 128 .BR execve (2)
 129 or an exit occurred.
 130 The parent process was suspended while the
 131 child was using its resources.
 132 The use of
 133 .BR vfork ()
 134 was tricky: for example, not modifying data
 135 in the parent process depended on knowing which variables were
 136 held in a register.
 137 .SH VERSIONS
 138 The requirements put on
 139 .BR vfork ()
 140 by the standards are weaker than those put on
 141 .BR fork (2),
 142 so an implementation where the two are synonymous is compliant.
 143 In particular, the programmer cannot rely on the parent
 144 remaining blocked until the child either terminates or calls
 145 .BR execve (2),
 146 and cannot rely on any specific behavior with respect to shared memory.
 147 .\" In AIXv3.1 vfork is equivalent to fork.
 148 .P
 149 Some consider the semantics of
 150 .BR vfork ()
 151 to be an architectural blemish, and the 4.2BSD man page stated:
 152 \[lq]This system call will be eliminated
 153 when proper system sharing mechanisms are implemented.
 154 Users should not depend on the memory sharing semantics of
 155 .I vfork
 156 as it will, in that case, be made synonymous to
 157 .IR fork .\[rq]
 158 However, even though modern memory management hardware
 159 has decreased the performance difference between
 160 .BR fork (2)
 161 and
 162 .BR vfork (),
 163 there are various reasons why Linux and other systems have retained
 164 .BR vfork ():
 165 .IP \[bu] 3
 166 Some performance-critical applications require the small performance
 167 advantage conferred by
 168 .BR vfork ().
 169 .IP \[bu]
 170 .BR vfork ()
 171 can be implemented on systems that lack a memory-management unit (MMU), but
 172 .BR fork (2)
 173 can't be implemented on such systems.
 174 (POSIX.1-2008 removed
 175 .BR vfork ()
 176 from the standard; the POSIX rationale for the
 177 .BR posix_spawn (3)
 178 function notes that that function,
 179 which provides functionality equivalent to
 180 .BR fork (2)+\c
 181 .BR exec (3),
 182 is designed to be implementable on systems that lack an MMU.)
 183 .\" http://stackoverflow.com/questions/4259629/what-is-the-difference-between-fork-and-vfork
 184 .\" http://developers.sun.com/solaris/articles/subprocess/subprocess.html
 185 .\" http://mailman.uclinux.org/pipermail/uclinux-dev/2009-April/000684.html
 186 .\"
 187 .IP \[bu]
 188 On systems where memory is constrained,
 189 .BR vfork ()
 190 avoids the need to temporarily commit memory (see the description of
 191 .I /proc/sys/vm/overcommit_memory
 192 in
 193 .BR proc (5))
 194 in order to execute a new program.
 195 (This can be especially beneficial where a large parent process wishes
 196 to execute a small helper program in a child process.)
 197 By contrast, using
 198 .BR fork (2)
 199 in this scenario requires either committing an amount of memory equal
 200 to the size of the parent process (if strict overcommitting is in force)
 201 or overcommitting memory with the risk that a process is terminated
 202 by the out-of-memory (OOM) killer.
 203 .SS Linux notes
 204 Fork handlers established using
 205 .BR pthread_atfork (3)
 206 are not called when a multithreaded program employing
 207 the NPTL threading library calls
 208 .BR vfork ().
 209 Fork handlers are called in this case in a program using the
 210 LinuxThreads threading library.
 211 (See
 212 .BR pthreads (7)
 213 for a description of Linux threading libraries.)
 214 .P
 215 A call to
 216 .BR vfork ()
 217 is equivalent to calling
 218 .BR clone (2)
 219 with
 220 .I flags
 221 specified as:
 222 .P
 223 .in +4n
 224 .EX
 225  CLONE_VM | CLONE_VFORK | SIGCHLD
 226 .EE
 227 .in
 228 .SH STANDARDS
 229 None.
 230 .SH HISTORY
 231 4.3BSD; POSIX.1-2001 (but marked OBSOLETE).
 232 POSIX.1-2008 removes the specification of
 233 .BR vfork ().
 234 .P
 235 The
 236 .BR vfork ()
 237 system call appeared in 3.0BSD.
 238 .\" In the release notes for 4.2BSD Sam Leffler wrote: `vfork: Is still
 239 .\" present, but definitely on its way out'.
 240 In 4.4BSD it was made synonymous to
 241 .BR fork (2)
 242 but NetBSD introduced it again;
 243 see
 244 .UR http://www.netbsd.org\:/Documentation\:/kernel\:/vfork.html
 245 .UE .
 246 In Linux, it has been equivalent to
 247 .BR fork (2)
 248 until Linux 2.2.0-pre6 or so.
 249 Since Linux 2.2.0-pre9 (on i386, somewhat later on
 250 other architectures) it is an independent system call.
 251 Support was added in glibc 2.0.112.
 252 .\"
 253 .SH CAVEATS
 254 The child process should take care not to modify the memory in unintended ways,
 255 since such changes will be seen by the parent process once
 256 the child terminates or executes another program.
 257 In this regard, signal handlers can be especially problematic:
 258 if a signal handler that is invoked in the child of
 259 .BR vfork ()
 260 changes memory, those changes may result in an inconsistent process state
 261 from the perspective of the parent process
 262 (e.g., memory changes would be visible in the parent,
 263 but changes to the state of open file descriptors would not be visible).
 264 .P
 265 When
 266 .BR vfork ()
 267 is called in a multithreaded process,
 268 only the calling thread is suspended until the child terminates
 269 or executes a new program.
 270 This means that the child is sharing an address space with other running code.
 271 This can be dangerous if another thread in the parent process
 272 changes credentials (using
 273 .BR setuid (2)
 274 or similar),
 275 since there are now two processes with different privilege levels
 276 running in the same address space.
 277 As an example of the dangers,
 278 suppose that a multithreaded program running as root creates a child using
 279 .BR vfork ().
 280 After the
 281 .BR vfork (),
 282 a thread in the parent process drops the process to an unprivileged user
 283 in order to run some untrusted code
 284 (e.g., perhaps via plug-in opened with
 285 .BR dlopen (3)).
 286 In this case, attacks are possible where the parent process uses
 287 .BR mmap (2)
 288 to map in code that will be executed by the privileged child process.
 289 .\"
 290 .SH BUGS
 291 Details of the signal handling are obscure and differ between systems.
 292 The BSD man page states:
 293 "To avoid a possible deadlock situation, processes that are children
 294 in the middle of a
 295 .BR vfork ()
 296 are never sent
 297 .B SIGTTOU
 298 or
 299 .B SIGTTIN
 300 signals; rather, output or
 301 .IR ioctl s
 302 are allowed and input attempts result in an end-of-file indication."
 303 .\"
 304 .\" As far as I can tell, the following is not true in Linux 2.6.19:
 305 .\" Currently (Linux 2.3.25),
 306 .\" .BR strace (1)
 307 .\" cannot follow
 308 .\" .BR vfork ()
 309 .\" and requires a kernel patch.
 310 .SH SEE ALSO
 311 .BR clone (2),
 312 .BR execve (2),
 313 .BR _exit (2),
 314 .BR fork (2),
 315 .BR unshare (2),
 316 .BR wait (2)