Re: [RFC PATCH 00/24] pidfd: add a minimal process spawn builder

[Li Chen]

Hi Justin,

 ---- On Wed, 05 Aug 2026 04:25:25 +0800  Justin Suess <utilityemal77@xxxxxxxxx> wrote --- 
 > On Thu, Jul 16, 2026 at 10:31:26PM +0800, Li Chen wrote:
 > > Hi,
 > > 
 > > This RFC follows feedback on my earlier spawn_template RFC [1]. That
 > > proposal made caching the primary interface; this one starts with general
 > > process construction. Christian suggested a pidfd/pidfs exec builder
 > > modeled after fsconfig(), with enough semantics for userspace to implement
 > > posix_spawn() [2], and Kees agreed [3].
 > > 
 > > This RFC is based on linux-next next-20260710 and depends on two pidfs
 > > fixes that I sent separately:
 > > 
 > >   * pidfs: preserve thread pidfds reopened by file handle
 > >     https://lore.kernel.org/all/20260716052726.1032092-1-me@linux.beauty/
 > >   * pidfs: handle FS_IOC32_GETVERSION in compat ioctl
 > >     https://lore.kernel.org/all/20260716052822.1034228-1-me@linux.beauty/
 > > 
 > > The initial implementation is source-based. The executable path can be
 > > provided with the final run request:
 > > 
 > >     struct pidfd_spawn_run_args run = {
 > >         .path = (unsigned long)"/usr/bin/rg",
 > This should probably be an FD for the path.
 > 
 > This way it prevents race conditions over multiple configuration steps.

Thanks, that makes sense. Using an fd avoids the pathname race and pins
the executable we actually want to run.

 > >         .argv = (unsigned long)argv,
 > >         .envp = (unsigned long)envp,
 > >     };
 > > 
 > >     fd = pidfd_open(0, PIDFD_EMPTY);
 > >     pidfd_spawn_run(fd, &run, sizeof(run));
 > > 
 > > Alternatively, the path can be staged before the final run step:
 > > 
 > >     struct pidfd_spawn_run_args run = {
 > >         .argv = (unsigned long)argv,
 > >         .envp = (unsigned long)envp,
 > >     };
 > > 
 > >     fd = pidfd_open(0, PIDFD_EMPTY);
 > >     pidfd_config(fd, PIDFD_CONFIG_SET_STRING,
 > >                  PIDFD_CONFIG_KEY_PATH, "/usr/bin/rg", 0);
 > Same here. Should probably be an FD to the binary instead.
 > 
 > >     pidfd_spawn_run(fd, &run, sizeof(run));
 > I'm worried this pidfd_spawn_run just adds another varient to the existing
 > myriad of exec* syscalls we already have. Would it be better to just have this
 > work through execveat(fd, "", argv, envp, AT_EMPTY_PATH) instead?
 > 
 > (i.e have execveat take a pidfd directly).
 > 
 > Then you can get rid of pidfd_spawn_run which looks almost structurally
 > identical to execveat (with the argv and envp collapsed).

Thanks, but I'm less sure about using execveat() as the run operation, since it
normally replaces the caller while the builder creates a new child and
returns. A separate run operation still seems clearer to me.

Regards,
Li​