View source for Pidfd

Since [[Linux_APIs|Linux 5.1]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.

The first "pidfds" were created by opening a <tt>/proc/PID</tt> directory, and used with <tt>pidfd_send_signal(2)</tt>. These pidfds are now considered incomplete (they cannot be polled for process termination, nor can they be used with the <tt>waitid(2)</tt> system call).

==Kernel==
At the heart of the modern pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with <tt>clone3(2)</tt>.

Kernel 5.3 introduced <tt>pidfd_open(2)</tt>, allowing a pidfd to be opened for an arbitrary existing process. If you for some reason can't use <tt>clone3(2)</tt>, this can be employed together with <tt>fork(2)</tt> for a race-free pidfd acquisition on children (see <tt>pidfd_spawn(3)</tt> below).

Kernel 5.6 added <tt>pidfd_getfd(2)</tt>, supporting duplication of an existing file descriptor in a process identified by a pidfd. This operation requires <tt>PTRACE_MODE_ATTACH_REALCREDS</tt>.

Kernel 5.8 added support for supplying a pidfd to <tt>setns(2)</tt>.

Kernel 5.10 brought <tt>process_madvise(2)</tt>, generalizing <tt>madvise(2)</tt> to multiple memory regions and allowing it to be applied to another process's address space. When used on another process (as opposed to oneself), it requires <tt>PTRACE_MODE_READ_FSCREDS</tt> and <tt>CAP_SYS_NICE</tt>.

As of 6.5, credentials can be sent using pidfds rather than <tt>SCM_CREDENTIALS</tt>-style PIDs using the <tt>SCM_PIDFD</tt> type. <tt>getsockopt(2)</tt> can use <tt>SO_PEERPIDFD</tt> to get a pidfd for the peer process on a <tt>unix(7)</tt> socket.

6.9 introduces pidfdfs, a pseudo filesystem similar to nsfs (<tt>/proc/PID/ns</tt>).

==[[Glibc]]==
GNU libc added pidfd system call support in 2.36. Glibc 2.39 added two functions for pidfds, complementing <tt>posix_spawn(3)</tt>. They return pidfds rather than PIDs:
* <tt>pidfd_spawn(3)</tt>:analogous to <tt>posix_spawn(3)</tt>
* <tt>pidfd_spawnp(3)</tt>: analogous to <tt>posix_spawnp(3)</tt>

The <tt>posix_spawnattr_t</tt> argument allows (among other things) spawning the process within a different control group.

Also added was <tt>pidfd_getpid(3)</tt>:

* <tt>pid_t pidfd_getpid(3)</tt>: get the PID from a pidfd

==See also==
* [https://lwn.net/Articles/943022/ Race-free process creation in the GNU C library], LWN
* [https://lwn.net/Articles/943022/ GNU C Library version 2.39], LWN

[[Category: Linux]]