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

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Alexey Izbyshev from comment #3)
> > 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.

It makes sense indeed.

> 
> > 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.

We discussed this before and we moved to use shared memory to report errors
exactly to avoid requiring another resource allocation (which adds even more
failure paths).  I am not very found in restoring it.

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