posix: Use posix_spawn on popen

This patch uses posix_spawn on popen instead of fork and execl.  On Linux
this has the advantage of much lower memory consumption (usually 32 Kb
minimum for the mmap stack area).

Two issues are also fixed with this change:

  * BZ#17490: although POSIX pthread_atfork description only list 'fork'
    as the function that should execute the atfork handlers, popen
    description states that:

      '[...] shall be *as if* a child process were created within the popen()
       call using the fork() function [...]'

    Other libc/system seems to follow the idea atfork handlers should not be
    executed for popen:

    libc/system	| run atfork handles   | notes
    ------------|----------------------|---------------------------------------
    Freebsd	|        no            | uses vfork
    Solaris 11	|        no            |
    MacOSX 11   |        no            | implemented through posix_spawn syscall
    ------------|----------------------|----------------------------------------

    Similar to posix_spawn and system, popen idea is to spawn a different
    binary so all the POSIX rationale to run the atfork handlers to avoid
    internal process inconsistency is not really required and in some cases
    might be unsafe.

  * BZ#22834: the described scenario, where the forked process might access
    invalid memory due an inconsistent state in multithreaded environment,
    should not happen because posix_spawn does not access the affected
    data structure (proc_file_chain).

Checked on x86_64-linux-gnu and i686-linux-gnu.

	[BZ #22834]
	[BZ #17490]
	* NEWS: Add new semantic for atfork with popen and system.
	* libio/iopopen.c (_IO_new_proc_open): use posix_spawn instead of
	fork and execl.

1 files changed, 6 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index 1098be1..8483dcf 100644
--- a/NEWS
+++ b/NEWS
@@ -35,6 +35,12 @@ Major new features:
   different directory.  This is a GNU extension and similar to the
   Solaris function of the same name.
 
+* The popen and system do not run atfork handlers anymore (BZ#17490).
+  Although it is a possible POSIX violation, the POSIX rationale in
+  pthread_atfork documentation regarding atfork handlers is to handle
+  incosistent mutex state after fork call in multithread environment.
+  In both popen and system there is no direct access to user-defined mutexes.
+
 Deprecated and removed features, and other changes affecting compatibility:
 
 * The glibc.tune tunable namespace has been renamed to glibc.cpu and the