[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=10354

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |bugdal at aerifal dot cx
         Resolution|WONTFIX                     |

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2011-10-10 03:08:20 UTC ---
The excuse for not fixing this does not make sense. The syscalls could be used
directly (without the wrapper code for cancellation), or cancellation could
simply be disabled by the parent prior to vfork and reenabled by the parent
after vfork returns (which won't happen until the child calls exec).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10354

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-10-15 13:47:29 UTC ---
(In reply to comment #2)
> The excuse for not fixing this does not make sense.

What doesn't make sense is you.  The function is defined in terms of using
close, open etc.  The semantics is fixed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=10354

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> 2011-10-15 20:52:20 UTC ---
It's defined in terms of open, close, etc. happening in the context of the
child process, where cancellation cannot play any role since there's no way to
obtain a pthread_t value referring to a thread in the child. Of course
implementing posix_spawn using vfork causes the cancellation state to be shared
with the parent, which would be problematic unless special care is made to
protect the state. I suggested several ways this could be done to allow vfork
to be used for posix_spawn in all cases.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=10354

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2012-10-21 16:59:58 UTC ---
This bug was marked "fixed" for no apparent reason. The issues reported still
exist; vfork is not used if any non-default attributes or file actions are
present. This makes it impossible to use posix_spawn from extremely large
processes due to commit charge exhaustion.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[sionescu+BugTrackers at cddr dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Stelian Ionescu <sionescu+BugTrackers at cddr dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sionescu+BugTrackers at cddr dot o
                   |                            |rg

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #6 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[P at draigBrady dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Pádraig Brady <P at draigBrady dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |P at draigBrady dot com

--- Comment #7 from Pádraig Brady <P at draigBrady dot com> ---
It's important that posix_spawn() avoids fork() where possible as that's the
whole reason for having this interface. I see that one can force using
vfork() with the POSIX_SPAWN_USEVFORK flag as mentioned in bug #378
though then you're on your own wrt safety.

So I'm wondering what specifically callers of posix_spawn() would
have to be careful to do?
  * Not setup pthread_atfork() handlers
  * pthread_setcancelstate(PTHREAD_CANCEL_DISABLE,  NULL); first (and enable
after)
  * anything else?

Also I was wondering whether some restrictions could be lifted in
the implementation by using clone() rather than vfork().
I.E. vfork() where possible to support MMU less systems,
but then fall back to clone(..., CLONE_VM | SIGCHLD, ...);
to at least have an otherwise efficient implementation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-22432-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed May 28 04:24:17 2014
Return-Path: <glibc-bugs-return-22432-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 28722 invoked by alias); 28 May 2014 04:24:12 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 28678 invoked by uid 48); 28 May 2014 04:24:06 -0000
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/10354] posix_spawn should use vfork() in more cases than presently
Date: Wed, 28 May 2014 04:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugdal at aerifal dot cx
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-10354-131-IMQqgNQHy6@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-10354-131@http.sourceware.org/bugzilla/>
References: <bug-10354-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00215.txt.bz2
Content-length: 859

https://sourceware.org/bugzilla/show_bug.cgi?id\x10354

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
Using clone with CLONE_VM and a new stack/start-function solves most of the
insurmountable problems with vfork that make it unsafe, but there are still a
number of considerations that come from sharing memory. In particular, you must
ensure that no signal handlers run in the child while it's sharing memory with
the parent, and the parent must be responsible for freeing the child's stack,
and thus must synchronize with the execve call in the child.

I have a working implementation in musl which solves these problems (it uses
clone with CLONE_VM for all posix_spawn operations) if anyone is interested in
looking at it and doing something similar for glibc.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |
                   |jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |
                   |jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #8)
> Using clone with CLONE_VM and a new stack/start-function solves most of the
> insurmountable problems with vfork that make it unsafe, but there are still
> a number of considerations that come from sharing memory. In particular, you
> must ensure that no signal handlers run in the child while it's sharing
> memory with the parent, and the parent must be responsible for freeing the
> child's stack, and thus must synchronize with the execve call in the child.
> 
> I have a working implementation in musl which solves these problems (it uses
> clone with CLONE_VM for all posix_spawn operations) if anyone is interested
> in looking at it and doing something similar for glibc.

I agree this issue should be fixed.

posix_spawn() could use vfork() in many more cases than it does today, and
cancellation is no excuse not to fix this. I agree that cancellation in the
context of the child doesn't make any sense. The child needs to just not touch
the cancel state, and with signals blocked it will never act on a SIGCANCEL
request anyway.

We can perhaps revisit this after we fix cancellation to work correctly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=10354

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10354] posix_spawn should use vfork() in more cases than presently

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2009-10-30 06:32 -------
No.  All file operations are cancellation points.  This cannot be done after vfork.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=10354

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.