[Bug libc/29115] vfork()-based posix_spawn() has more failure modes than fork()-based one

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #10 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Alexey Izbyshev from comment #7)
> (In reply to Carlos O'Donell from comment #5)
> > Either the kernel supports vfork or it doesn't.
> > 
> > A time namespace, or a seccomp filter are all the same problems, and we
> > should return the error the userspace.
> > 
> > Adding code which will only be exercised in the event that a time namespace
> > is in use is going to result in increased long-term maintenance costs.
> > 
> > It also results in unexpected surprise behaviour when the developer runs
> > under a time namespace e.g. more memory usage, different code paths taken
> > etc.
> > 
> > Rather than add long-term maintenance and surprise developers my suggestion
> > is to fail the posix_spawn.
> > 
> posix_spawn() failing and fork()/exec() not failing is also a surprise for
> developers. Note that if users are expected to deal with this posix_spawn()
> failure, all language frameworks/libraries providing high level process
> creation APIs will have to implement knobs to opt-out from posix_spawn().
> It's not clear to me that it's better than a potential performance problem
> due to fork() when time namespaces are used.
> 
> We also don't know what other vfork() failure modes that fork() doesn't have
> may appear in the future. A fallback would cover them.

That is a slipper slope fallacy. Those other failure modes haven't materialized
and so they do not matter to the conversation at hand. When we have other
failure modes, and fork() can fail badly also as it consumes more memmory,
maybe triggering OOM, we have other problems.

Performance and expected semantics are an important part of an interface.
Library and applications authors would not only have to change posix_spawn() as
a choice but also system() which may use vfork(), and maybe even clone (if used
with the right flags).

All of this makes me suspect that blocking vfork is the wrong semantic. It
needs to be enabled in the kernel otherwise the CRIU use case is *not met*.

We can't add CLONE_NEWTIME and yet require all of userspace to move away from
vfork/clone which is the fastest and least-memory intensive way to clone a
process.

This change adds significant code to the implementation. Please involve the
CRIU developers and see if this can't be solved in the kernel first. I haven't
seen any justification that there are blockers to this in the kernel.

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