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

["izbyshev at ispras dot ru" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #3 from Alexey Izbyshev <izbyshev at ispras dot ru> ---
> It is really annoying that kernel does not allow clone (CLONE_VM |
> CLONE_VFORK)
> with time namespace, however I am not the implications of allowing it
> (neither
> if this is feasible on current kernel architecture).  
> 
I suspect this restriction is due to the conflict of the shared address space
and the need to provide different VDSOs (for clock_gettime()) for processes in
separate time namespaces, but I haven't looked closely.

> In any case, adding fork+exec fallback seems feasible, the only annoying
> case is
> if glibc should detect a clone transient failure (for instance due some
> resource
> exhaustion) from a namespace filtering. We can always retry in case of clone
> failure, it should be really an exception and retrying will most likely
> succeed
> in both cases.

I think it would be great if glibc provided such a fallback. I agree that
retrying once with fork() in case of *any* clone(CLONE_VM | CLONE_VFORK)
failure shouldn't hurt, but it should probably also be OK to skip retry on
ENOMEM and (paradoxically) EAGAIN because the caller has to deal with them in
any case.

> Another issue is with fork+exec fallback it would require additional
> resources to communicate the possible error code from the helper process
> while running the prepare phase (as covered by tst-spawn3.c).

Yes, I'm aware that glibc currently relies on address space sharing to pass the
error code, so adding an alternative error reporting would constitute most of
the fix.

One benefit of the alternative error reporting is that it would also work
correctly in environments where vfork() system call acts as fork() (i.e.
doesn't provide address space sharing), such as qemu-user. So if it's in place,
glibc could add some knob to always enable it for users that need good
posix_spawn() error reporting in such environments.

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