1 files changed, 47 insertions, 45 deletions
diff --git a/man2/vfork.2 b/man2/vfork.2
index 5e6b8226c3..3a65010cab 100644
--- a/man2/vfork.2
+++ b/man2/vfork.2
@@ -134,11 +134,7 @@ The use of
 was tricky: for example, not modifying data
 in the parent process depended on knowing which variables were
 held in a register.
-.SH STANDARDS
-4.3BSD; POSIX.1-2001 (but marked OBSOLETE).
-POSIX.1-2008 removes the specification of
-.BR vfork ().
-.PP
+.SH VERSIONS
 The requirements put on
 .BR vfork ()
 by the standards are weaker than those put on
@@ -149,7 +145,7 @@ remaining blocked until the child either terminates or calls
 .BR execve (2),
 and cannot rely on any specific behavior with respect to shared memory.
 .\" In AIXv3.1 vfork is equivalent to fork.
-.SH NOTES
+.PP
 Some consider the semantics of
 .BR vfork ()
 to be an architectural blemish, and the 4.2BSD man page stated:
@@ -205,44 +201,6 @@ 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)
@@ -268,7 +226,13 @@ specified as:
  CLONE_VM | CLONE_VFORK | SIGCHLD
 .EE
 .in
-.SS History
+.SH STANDARDS
+None.
+.SH HISTORY
+4.3BSD; POSIX.1-2001 (but marked OBSOLETE).
+POSIX.1-2008 removes the specification of
+.BR vfork ().
+.PP
 The
 .BR vfork ()
 system call appeared in 3.0BSD.
@@ -286,6 +250,44 @@ until Linux 2.2.0-pre6 or so.
 Since Linux 2.2.0-pre9 (on i386, somewhat later on
 other architectures) it is an independent system call.
 Support was added in glibc 2.0.112.
+.\"
+.SH 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.
+.\"
 .SH BUGS
 Details of the signal handling are obscure and differ between systems.
 The BSD man page states: