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 2022-09-09 "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 .PP
  19 .B pid_t vfork(void);
  20 .fi
  21 .PP
  22 .RS -4
  23 Feature Test Macro Requirements for glibc (see
  24 .BR feature_test_macros (7)):
  25 .RE
  26 .PP
  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 .PP
  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 .PP
  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 .PP
  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 .PP
 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 STANDARDS
 138 4.3BSD; POSIX.1-2001 (but marked OBSOLETE).
 139 POSIX.1-2008 removes the specification of
 140 .BR vfork ().
 141 .PP
 142 The requirements put on
 143 .BR vfork ()
 144 by the standards are weaker than those put on
 145 .BR fork (2),
 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
 149 .BR execve (2),
 150 and cannot rely on any specific behavior with respect to shared memory.
 151 .\" In AIXv3.1 vfork is equivalent to fork.
 152 .SH NOTES
 153 Some consider the semantics of
 154 .BR vfork ()
 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
 157 are implemented.
 158 Users should not depend on the memory sharing semantics of
 159 .BR vfork ()
 160 as it will, in that case, be made synonymous to
 161 .BR fork (2).\c
 162 "
 163 However, even though modern memory management hardware
 164 has decreased the performance difference between
 165 .BR fork (2)
 166 and
 167 .BR vfork (),
 168 there are various reasons why Linux and other systems have retained
 169 .BR vfork ():
 170 .IP * 3
 171 Some performance-critical applications require the small performance
 172 advantage conferred by
 173 .BR vfork ().
 174 .IP *
 175 .BR vfork ()
 176 can be implemented on systems that lack a memory-management unit (MMU), but
 177 .BR fork (2)
 178 can't be implemented on such systems.
 179 (POSIX.1-2008 removed
 180 .BR vfork ()
 181 from the standard; the POSIX rationale for the
 182 .BR posix_spawn (3)
 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
 190 .\"
 191 .IP *
 192 On systems where memory is constrained,
 193 .BR vfork ()
 194 avoids the need to temporarily commit memory (see the description of
 195 .I /proc/sys/vm/overcommit_memory
 196 in
 197 .BR proc (5))
 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.)
 201 By contrast, using
 202 .BR fork (2)
 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.
 207 .\"
 208 .SS Caveats
 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
 214 .BR vfork ()
 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).
 219 .PP
 220 When
 221 .BR vfork ()
 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
 228 .BR setuid (2)
 229 or similar),
 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
 234 .BR vfork ().
 235 After the
 236 .BR vfork (),
 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
 240 .BR dlopen (3)).
 241 In this case, attacks are possible where the parent process uses
 242 .BR mmap (2)
 243 to map in code that will be executed by the privileged child process.
 244 .\"
 245 .SS Linux notes
 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
 250 .BR vfork ().
 251 Fork handlers are called in this case in a program using the
 252 LinuxThreads threading library.
 253 (See
 254 .BR pthreads (7)
 255 for a description of Linux threading libraries.)
 256 .PP
 257 A call to
 258 .BR vfork ()
 259 is equivalent to calling
 260 .BR clone (2)
 261 with
 262 .I flags
 263 specified as:
 264 .PP
 265 .in +4n
 266 .EX
 267  CLONE_VM | CLONE_VFORK | SIGCHLD
 268 .EE
 269 .in
 270 .SS History
 271 The
 272 .BR vfork ()
 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
 277 .BR fork (2)
 278 but NetBSD introduced it again;
 279 see
 280 .UR http://www.netbsd.org\:/Documentation\:/kernel\:/vfork.html
 281 .UE .
 282 In Linux, it has been equivalent to
 283 .BR fork (2)
 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.
 288 .SH BUGS
 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
 292 in the middle of a
 293 .BR vfork ()
 294 are never sent
 295 .B SIGTTOU
 296 or
 297 .B SIGTTIN
 298 signals; rather, output or
 299 .IR ioctl s
 300 are allowed and input attempts result in an end-of-file indication."
 301 .\"
 302 .\" As far as I can tell, the following is not true in 2.6.19:
 303 .\" Currently (Linux 2.3.25),
 304 .\" .BR strace (1)
 305 .\" cannot follow
 306 .\" .BR vfork ()
 307 .\" and requires a kernel patch.
 308 .SH SEE ALSO
 309 .BR clone (2),
 310 .BR execve (2),
 311 .BR _exit (2),
 312 .BR fork (2),
 313 .BR unshare (2),
 314 .BR wait (2)