[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 #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Alexey Izbyshev from comment #0)
> Modern vfork()-based posix_spawn() can be used as an efficient alternative
> to fork()/exec() to avoid performance and overcommit issues. A common
> expectation is that whenever posix_spawn() feature set is sufficient for
> application needs of tweaking the child attributes, it can be used instead
> of fork()/exec().
> 
> However, it turns out that vfork() can have failure modes than fork()
> doesn't have. One such case is due to Linux not allowing processes in
> different time namespaces to share address space.
> 
> $ cat test.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <spawn.h>
> #include <unistd.h>
> 
> int main(int argc, char *argv[], char *envp[]) {
>   if (getenv("TEST_FORK")) {
>     pid_t pid = fork();
>     if (pid < 0) {
>         perror("fork");
>         return 127;
>     }
>     if (pid == 0) {
>         execve(argv[1], argv + 1, envp);
>         perror("execve");
>         return 127;
>     }
>   } else {
>       int err = posix_spawn(0, argv[1], 0, 0, argv + 1, envp);
>       if (err) {
>         printf("posix_spawn: %s\n", strerror(err));
>         return 127;
>       }
>   }
>   printf("OK\n");
>   return 0;
> }
> 
> $ gcc test.c
> 
> $ unshare -UrT ./a.out /bin/true
> posix_spawn: Operation not permitted
> 
> (The actual clone() error is EINVAL, but it's reported incorrectly due to
> bug 29109).
> 
> $ TEST_FORK=1 unshare -UrT ./a.out /bin/true
> OK
> 
> I'm not aware of other failure modes, but more might appear in the future.
> 
> Does this qualify as a glibc bug? Should glibc's posix_spawn()
> implementation, for example, retry with fork() on vfork() failure (which
> would require a redesign of error reporting from the child process because
> it currently relies on address space sharing)?
> 
> Or do applications are expected to deal with that somehow? In this case,
> what is the recommended way to do that, given that it's not possible to
> reliably detect "retriable" posix_spawn() failures?

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

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.

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