public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/29115] vfork()-based posix_spawn() has more failure modes than fork()-based one
Date: Mon, 02 May 2022 21:02:09 +0000 [thread overview]
Message-ID: <bug-29115-131-7Ya3dbwJK5@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-29115-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=29115
--- Comment #8 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #6)
> CLONE_NEWTIME is as specified today fundamentally incompatible with real
> vfork and the vDSO. It just does not work. Entering the new namespace
> requires a new vDSO data mapping, and that conflicts with vfork using the
> same address space.
The kernel already has per-cpu data in the vDSO.
The vDSO doesn't follow any concept of a single address space for the process.
The vDSO is not a part of POSIX and so doesn't have to follow any vfork
semantic requirements.
What prevents the kernel from making a new vDSO data mapping?
> CLONE_NEWTIME should have been specified to apply only after execve (which
> remaps the vDSO anyway), but it it's what we've got.
It can remain that way, we just have to remap the vDSO at vfork time?
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2022-05-02 21:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 12:08 [Bug libc/29115] New: " izbyshev at ispras dot ru
2022-05-02 12:09 ` [Bug libc/29115] " izbyshev at ispras dot ru
2022-05-02 16:17 ` adhemerval.zanella at linaro dot org
2022-05-02 16:26 ` adhemerval.zanella at linaro dot org
2022-05-02 16:55 ` izbyshev at ispras dot ru
2022-05-02 17:17 ` adhemerval.zanella at linaro dot org
2022-05-02 18:04 ` adhemerval.zanella at linaro dot org
2022-05-02 20:38 ` carlos at redhat dot com
2022-05-02 20:43 ` fweimer at redhat dot com
2022-05-02 20:56 ` izbyshev at ispras dot ru
2022-05-02 21:02 ` carlos at redhat dot com [this message]
2022-05-02 21:06 ` fweimer at redhat dot com
2022-05-02 21:15 ` carlos at redhat dot com
2022-05-02 21:24 ` carlos at redhat dot com
2022-05-02 21:51 ` adhemerval.zanella at linaro dot org
2022-08-08 14:08 ` adhemerval.zanella at linaro dot org
2022-08-08 14:13 ` fweimer at redhat dot com
2022-08-08 14:15 ` fweimer at redhat dot com
2022-08-08 15:37 ` izbyshev at ispras dot ru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-29115-131-7Ya3dbwJK5@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=glibc-bugs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).