mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Rich Felker <dalias@libc.org>
Cc: Alexey Izbyshev <izbyshev@ispras.ru>,  musl@lists.openwall.com
Subject: Re: [musl] vfork()-based posix_spawn() has more failure modes than fork()-based one
Date: Mon, 02 May 2022 23:25:07 +0200	[thread overview]
Message-ID: <8735hr4ogc.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20220502211856.GR7074@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 2 May 2022 17:18:56 -0400")

* Rich Felker:

> I'm trying to understand how this comes to be. The child should
> inherit the namespaces of the parent and thus should not be in a
> different namespace that precludes spawn. I'm guessing this is some
> oddity where unshare doesn't affect the process itself, only its
> children? If so, it seems like a bug that it doesn't affect the
> process itself after execve (after unshare(1) runs your test program),
> but that probably can't be fixed now on the Linux side for stability
> reasons. :(

It's about fundamentally conflicting requirements.

The vDSO data mapping needs to store the time offset, so it has to be
distinct from the original namespace.  vfork preserves the VM sharing.
It's not possible to do both things at the same time.

unshare(CLONE_NEWTIME) should have been specified to only take effect
after execve, when the vDSO is remapped anyway.

Thanks,
Florian


  reply	other threads:[~2022-05-02 21:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-02 19:26 Alexey Izbyshev
2022-05-02 20:49 ` Carlos O'Donell
2022-05-02 21:18 ` Rich Felker
2022-05-02 21:25   ` Florian Weimer [this message]
2022-05-02 21:31     ` Rich Felker
2023-02-22 22:04       ` Alexey Izbyshev
2022-05-02 21:31     ` Carlos O'Donell
2022-05-02 21:49       ` Alexey Izbyshev
2022-05-02 21:56         ` Alexey Izbyshev

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=8735hr4ogc.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=dalias@libc.org \
    --cc=izbyshev@ispras.ru \
    --cc=musl@lists.openwall.com \
    /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. 
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).