From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 552DA3954449 for ; Tue, 3 May 2022 16:37:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 552DA3954449 Received: by mail-oi1-x230.google.com with SMTP id r1so18532509oie.4 for ; Tue, 03 May 2022 09:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=d5NVG4qEq2iUl/bCOvtUMSNduKXHbSnTneAnCfCVA0M=; b=KDRZi84x0Soz4sfW2+Bbm8F9PjLRvzVh1eE67FRbZnOjl0kIqRIS85WM3NYFpoXUMm t3cxct0QCmfm5v7lvrVl6Y6UFBEit+fBey/PXTIuoSZ2yTWUw97TNQfL1dLLbBfK1VcN lAt8DIKtGyCkOmzqssNlUnWGTCvjmdrTDv1o0T+D7lPaGnExjK9iymw7mMCQaRUt6KqN ycvMrRGjTAUkI0nsz9fzvPMLjyqPLBSqPmRnqpejqpirNxwEo1kZbH+RnWjtNK3lC5V9 A4RHhKs1s2y2RmEoFPA45cLeR13Tmerz8tu14/nJQLJT3XzRauB/4PrAbgZ1Qq6EzVz+ p3PQ== X-Gm-Message-State: AOAM532LHr9CeHJMqMww+H4/UYGq1XZeDnVFdGrle3yI3vKjhcs51bE/ pk1qIQCo0zQ8LCJF9Z1XiVMf8A== X-Google-Smtp-Source: ABdhPJx8KihFTS+0+I5G+Pkd0XYNck1dFDc3oNn0DbeeS5zvBvXfUgTgLHS8WG+VrKRjJiVgBVS1PQ== X-Received: by 2002:a05:6808:144d:b0:325:a744:1581 with SMTP id x13-20020a056808144d00b00325a7441581mr2132065oiv.26.1651595856417; Tue, 03 May 2022 09:37:36 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:726:bb0f:4f0c:a44b:4ae1? ([2804:431:c7cb:726:bb0f:4f0c:a44b:4ae1]) by smtp.gmail.com with ESMTPSA id e2-20020a4aa602000000b0035ef3da8387sm2144853oom.4.2022.05.03.09.37.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 May 2022 09:37:35 -0700 (PDT) Message-ID: Date: Tue, 3 May 2022 13:37:32 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v2] linux: Add fallback for clone failure on posix_spawn (BZ#29115) Content-Language: en-US To: Alexey Izbyshev Cc: libc-alpha@sourceware.org, Carlos O'Donell , Florian Weimer References: <20220503134625.2389370-1-adhemerval.zanella@linaro.org> <6cfe491d693980693b867879bc4e2d9f@ispras.ru> From: Adhemerval Zanella In-Reply-To: <6cfe491d693980693b867879bc4e2d9f@ispras.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2022 16:37:40 -0000 On 03/05/2022 13:06, Alexey Izbyshev wrote: > On 2022-05-03 16:46, Adhemerval Zanella wrote: >> Even though it might characterizeis as a kernel bug (incomplete kernel >> support for CLONE_VM used along with CLONE_VFORK), time namespace support >> is already presented in a some kernel releases (since 2020). >> >> Although I agree with Carlos that it results in unexpected surprise >> behaviour, I also see that providing a reasonable fallback that does not >> add possible issues like race conditions (as some syscall fallbacks in the >> past) provides a easier transition and make the interfaca to work on >> multiple scenarios. >> >> The fix itself does adds some corner cases that need to be handled, but >> I still think it is maintanable and a general improvement. >> >> -- >> >> Linux clone with CLONE_VM may fail for some namespace restriction (for >> instance if kernel does not allow processes in different time namespaces >> to share the sameaddress space). >> >> In this case clone fails with EINVAL and posix_spawn can not spawn a new >> process.  However the same process can be spawned with fork and exec. >> >> The patch fixes by retrying the clone syscall with just CLONE_VFORK >> if clone fails with a non transient failure (ENOMEM and EAGAIN still >> returns failure to caller). >> >> Error on preparation phase or execve is returned by a pipe now that >> there is no shared memory that ca be used.  It requires some extra care >> for some file operations: >> >>   * If the file operation would clobber the pipe file descriptor, the >>     helper process dup the pipe onto an unoccupied file descriptor. >> >>   * dup2 file action that targets the pipe file descriptor returns >>     EBADF. >> >>   * If closefrom argument overlaps the pipe file descriptor, it is >>     splited in two calls: [lowdp, pipe - 1] and [pipe + 1, ~Ou]. >> >> Failure on prepare phase in helper process does not trigger the fork >> and exec fallback. >> >> Checked on x86_64-linux-gnu. >> --- >>  sysdeps/unix/sysv/linux/spawni.c | 231 +++++++++++++++++++++++++------ >>  1 file changed, 185 insertions(+), 46 deletions(-) >> >> diff --git a/sysdeps/unix/sysv/linux/spawni.c b/sysdeps/unix/sysv/linux/spawni.c >> index d6f5ca89cd..e17b1967ef 100644 >> --- a/sysdeps/unix/sysv/linux/spawni.c >> +++ b/sysdeps/unix/sysv/linux/spawni.c >> @@ -44,7 +44,11 @@ >>     third issue is done by a stack allocation in parent, and by using a >>     field in struct spawn_args where the child can write an error >>     code. CLONE_VFORK ensures that the parent does not run until the >> -   child has either exec'ed successfully or exited.  */ >> +   child has either exec'ed successfully or exited. >> + >> +   If the clone with CLONE_VM and CLONE_VFORK fails (due any kernel limitation >> +   such as time namespace), only CLONE_VFORK is used instead and the >> +   preparation and execve failures are communicated with a pipe.  */ >> >> >>  /* The Unix standard contains a long explanation of the way to signal >> @@ -67,6 +71,7 @@ struct posix_spawn_args >>    char *const *envp; >>    int xflags; >>    int err; >> +  int pipe[2]; >>  }; >> >>  /* Older version requires that shell script without shebang definition >> @@ -94,15 +99,59 @@ maybe_script_execute (struct posix_spawn_args *args) >>      } >>  } >> >> +/* If the file operation would clobber the pipe fd used to communite with >> +   parent, dup the pipe onto an unoccupied file descriptor.  */ >> +static inline bool >> +spawni_fa_handle_pipe (const struct __spawn_action *fa, int p[]) >> +{ >> +  int fd; >> + >> +  switch (fa->tag) >> +    { >> +    case spawn_do_close: >> +      fd = fa->action.close_action.fd; >> +      break; >> +    case spawn_do_open: >> +      fd = fa->action.open_action.fd; >> +      break; >> +    case spawn_do_dup2: >> +      fd = fa->action.open_action.fd; > > "dup2_action.newfd" should be used here. Ack. > >> +      break; >> +    case spawn_do_fchdir: >> +      fd = fa->action.fchdir_action.fd; >> +    default: >> +      return true; >> +    } >> + >> +  if (fd == p[1]) >> +    { >> +      int r = __fcntl (p[1], F_DUPFD_CLOEXEC); >> +      if (r < 0) >> +    return false; >> +      __close_nocancel (p[1]); >> +      p[1] = r; >> +    } >> + >> +  return true; >> +} >> + >> +static inline bool >> +spawni_fa_closerange (int from, int to) >> +{ >> +  int r = INLINE_SYSCALL_CALL (close_range, from, to, 0); >> +  return r == 0 || __closefrom_fallback (from, false); > > "__closefrom_fallback" ignores "to", so it will close the error pipe on Linux kernels not supporting close_range(). Sigh, I forgot about it. > >> +} >> + >>  /* Function used in the clone call to setup the signals mask, posix_spawn >>     attributes, and file actions.  It run on its own stack (provided by the >>     posix_spawn call).  */ >> -static int >> -__spawni_child (void *arguments) >> +static _Noreturn int >> +spawni_child (void *arguments) >>  { >>    struct posix_spawn_args *args = arguments; >>    const posix_spawnattr_t *restrict attr = args->attr; >>    const posix_spawn_file_actions_t *file_actions = args->fa; >> +  bool use_pipe = args->pipe[0] != -1; >> >>    /* The child must ensure that no signal handler are enabled because it shared >>       memory with parent, so the signal disposition must be either SIG_DFL or >> @@ -113,6 +162,9 @@ __spawni_child (void *arguments) >>    struct sigaction sa; >>    memset (&sa, '\0', sizeof (sa)); >> >> +  if (use_pipe) >> +    __close (args->pipe[0]); >> + >>    sigset_t hset; >>    __sigprocmask (SIG_BLOCK, 0, &hset); >>    for (int sig = 1; sig < _NSIG; ++sig) >> @@ -181,6 +233,9 @@ __spawni_child (void *arguments) >>      { >>        struct __spawn_action *action = &file_actions->__actions[cnt]; >> >> +      if (use_pipe && !spawni_fa_handle_pipe (action, args->pipe)) >> +        goto fail; >> + >>        switch (action->tag) >>          { >>          case spawn_do_close: >> @@ -233,6 +288,11 @@ __spawni_child (void *arguments) >>            break; >> >>          case spawn_do_dup2: >> +          if (use_pipe && action->action.dup2_action.fd == args->pipe[1]) >> +        { >> +          errno = EBADF; >> +          goto fail; >> +        } >>            /* Austin Group issue #411 requires adddup2 action with source >>           and destination being equal to remove close-on-exec flag.  */ >>            if (action->action.dup2_action.fd >> @@ -264,8 +324,16 @@ __spawni_child (void *arguments) >>          case spawn_do_closefrom: >>            { >>          int lowfd = action->action.closefrom_action.from; >> -            int r = INLINE_SYSCALL_CALL (close_range, lowfd, ~0U, 0); >> -        if (r != 0 && !__closefrom_fallback (lowfd, false)) >> +        /* Skip the pipe descriptor if it is used.  No need to handle >> +           it since it created and duplicated with O_CLOEXEC.  */ >> +        if (use_pipe >> +            && args->pipe[1] > action->action.closefrom_action.from) > > Maybe it's better to use "lowfd" instead of "action->action.closefrom_action.from"? Ack. > >> +          { >> +            if (!spawni_fa_closerange (lowfd, args->pipe[1] - 1) >> +            || !spawni_fa_closerange (args->pipe[1] + 1, ~0U)) >> +              goto fail; >> +          } >> +        else if (!spawni_fa_closerange (lowfd, ~0U)) > > This will close the error pipe if "use_pipe && args->pipe[1] == low_fd". Ack. > >>            goto fail; >>            } break; >> >> @@ -300,10 +368,114 @@ fail: >>       (EINTERNALBUG) describing that, use ECHILD.  Another option would >>       be to set args->err to some negative sentinel and have the parent >>       abort(), but that seems needlessly harsh.  */ >> -  args->err = errno ? : ECHILD; >> +  int ret = errno ? : ECHILD; >> +  if (use_pipe) >> +    { >> +      while (__write_nocancel (args->pipe[1], &ret, sizeof (ret)) < 0) >> +    if (errno == EPIPE || errno == EBADF) >> +      break; >> +    } >> +  else >> +    args->err = ret; >> + >>    _exit (SPAWN_ERROR); >>  } >> >> +static pid_t >> +clone_call (struct posix_spawn_args *args, int flags, void *stack, >> +        size_t stack_size) >> +{ >> +  struct clone_args clone_args = >> +    { >> +      .flags = flags, >> +      .exit_signal = SIGCHLD, >> +      .stack = (uintptr_t) stack, >> +      .stack_size = stack_size, >> +    }; >> +  return __clone_internal (&clone_args, spawni_child, args); >> +} >> + >> +/* Spawn a new process using clone with CLONE_VM | CLONE_VFORK (to optimize >> +   memory and overcommit) and return TRUE if the helper was created or if the >> +   failure was not due resource exhaustion.  */ >> +static bool >> +spawni_clone (struct posix_spawn_args *args, pid_t *new_pid, int *ec, >> +          void *stack, size_t stack_size) >> +{ >> +  /* The clone flags used will create a new child that will run in the same >> +     memory space (CLONE_VM) and the execution of calling thread will be >> +     suspend until the child calls execve or _exit. >> + >> +     Also since the calling thread execution will be suspend, there is not >> +     need for CLONE_SETTLS.  Although parent and child share the same TLS >> +     namespace, there will be no concurrent access for TLS variables (errno >> +     for instance).  */ >> +  *new_pid = clone_call (args, CLONE_VM | CLONE_VFORK, stack, stack_size); >> + >> +  /* It needs to collect the case where the auxiliary process was created >> +     but failed to execute the file (due either any preparation step or >> +     for execve itself).  */ >> +  if (*new_pid > 0) >> +    { >> +      /* Also, it handles the unlikely case where the auxiliary process was >> +     terminated before calling execve as if it was successfully.  The >> +     args.err is set to 0 as default and changed to a positive value >> +     only in case of failure, so in case of premature termination >> +     due a signal args.err will remain zeroed and it will be up to >> +     caller to actually collect it.  */ >> +      *ec = args->err; >> +      if (*ec > 0) >> +    /* There still an unlikely case where the child is cancelled after >> +       setting args.err, due to a positive error value.  Also there is >> +       possible pid reuse race (where the kernel allocated the same pid >> +       to an unrelated process).  Unfortunately due synchronization >> +       issues where the kernel might not have the process collected >> +       the waitpid below can not use WNOHANG.  */ >> +    __waitpid (*new_pid, NULL, 0); >> +    } >> +  else >> +    *ec = errno; >> + >> +  /* There is no much point in retrying with fork and exec if kernel returns a >> +     failure due resource exhaustion.  */ >> +  return *new_pid > 0 || (errno == ENOMEM || errno == EAGAIN); >> +} >> + >> +/* Fallback spawn case which does not use CLONE_VM.  Any prepration step or >> +   execve failure is passed with a pipe, which requires additional care by >> +   the helper stating process since it additional file descriptors handle.  */ >> +static void >> +spawni_vfork (struct posix_spawn_args *args, pid_t *new_pid, int *ec, >> +          char *stack, size_t stack_size) >> +{ >> +  if (__pipe2 (args->pipe, O_CLOEXEC) != 0) >> +    { >> +      *ec = errno; >> +      return; >> +    } >> + >> +  /* Do not trigger atfork handler nor any internal state reset since the >> +     helper process will call execve.  */ >> +  *new_pid = clone_call (args, CLONE_VFORK, stack, stack_size); >> +  if (*new_pid == 0) >> +    spawni_child (args); > > spawni_child() is run in the child by clone_call(). Oops forgot to remove it. > >> + >> +  __close (args->pipe[1]); >> + >> +  if (*new_pid > 0) >> +    { >> +      if (__read (args->pipe[0], ec, sizeof *ec) != sizeof *ec) >> +    /* A successful execve will close the helper process pipe end.  */ >> +    *ec = 0; >> +      else >> +    __waitpid (*new_pid, NULL, 0); >> +    } >> +  else >> +    *ec = errno; >> + >> +  __close (args->pipe[0]); >> +} >> + >>  /* Spawn a new process executing PATH with the attributes describes in *ATTRP. >>     Before running the process perform the actions described in FILE-ACTIONS. */ >>  static int >> @@ -367,49 +539,16 @@ __spawnix (pid_t * pid, const char *file, >>    args.argc = argc; >>    args.envp = envp; >>    args.xflags = xflags; >> +  args.pipe[0] = args.pipe[1] = -1; >> >>    __libc_signal_block_all (&args.oldmask); >> >> -  /* The clone flags used will create a new child that will run in the same >> -     memory space (CLONE_VM) and the execution of calling thread will be >> -     suspend until the child calls execve or _exit. >> - >> -     Also since the calling thread execution will be suspend, there is not >> -     need for CLONE_SETTLS.  Although parent and child share the same TLS >> -     namespace, there will be no concurrent access for TLS variables (errno >> -     for instance).  */ >> -  struct clone_args clone_args = >> -    { >> -      .flags = CLONE_VM | CLONE_VFORK, >> -      .exit_signal = SIGCHLD, >> -      .stack = (uintptr_t) stack, >> -      .stack_size = stack_size, >> -    }; >> -  new_pid = __clone_internal (&clone_args, __spawni_child, &args); >> - >> -  /* It needs to collect the case where the auxiliary process was created >> -     but failed to execute the file (due either any preparation step or >> -     for execve itself).  */ >> -  if (new_pid > 0) >> -    { >> -      /* Also, it handles the unlikely case where the auxiliary process was >> -     terminated before calling execve as if it was successfully.  The >> -     args.err is set to 0 as default and changed to a positive value >> -     only in case of failure, so in case of premature termination >> -     due a signal args.err will remain zeroed and it will be up to >> -     caller to actually collect it.  */ >> -      ec = args.err; >> -      if (ec > 0) >> -    /* There still an unlikely case where the child is cancelled after >> -       setting args.err, due to a positive error value.  Also there is >> -       possible pid reuse race (where the kernel allocated the same pid >> -       to an unrelated process).  Unfortunately due synchronization >> -       issues where the kernel might not have the process collected >> -       the waitpid below can not use WNOHANG.  */ >> -    __waitpid (new_pid, NULL, 0); >> -    } >> -  else >> -    ec = errno; >> +  /* clone with CLONE_VM | CLONE_VFORK may fail for some namespace restriction >> +     (for instance Linux does not allow processes in different time namespaces >> +     to share address space) and in this case clone fails with EINVAL.  Retry >> +     with fork and exec.  */ >> +  if (!spawni_clone (&args, &new_pid, &ec, stack, stack_size)) >> +    spawni_vfork (&args, &new_pid, &ec, stack, stack_size); > > "spawni_vfork" seems like a very confusing name (especially in conjunction with the comment above), since here it means "use CLONE_VFORK without CLONE_VM" (which is more like fork()) instead of "use vfork()". I will rename again to spawni_fork, it makes more sense. >> >>    __munmap (stack, stack_size); > > I'm fine with the general approach (though the previous approach with _Fork()/exec() was also fine :) ) > > There are also some typos in comments, but anyway, in my understanding, there is currently no agreement among glibc developers on whether the issue should be fixed on the glibc side. There is a discussion at [1] which will hopefully attract kernel developers for clarifications. In particular, I'm very interested whether the kernel can commit to not breaking the ability to use vfork() instead of fork() any further. I think to have a working solution if kernel decides to not support it it a good thing to have, even if we decide to not fix it on glibc. > > Alexey > > [1] https://www.openwall.com/lists/musl/2022/05/02/1