Pidfd

Line 1:

Since [[Linux_APIs|Linux 5.2]], 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.

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.

At the heart of the 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>.

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

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.

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

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.

Pidfd: Difference between revisions

Dank (talk | contribs)

@@ Line 1: / Line 1: @@
-Since [[Linux_APIs|Linux 5.2]], 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.
+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.
-At the heart of the 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>.
+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).
+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.
+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>.
+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.