https://criu.org/api.php?action=feedcontributions&feedformat=atom&user=Bsach64CRIU - User contributions [en]2026-05-13T18:42:08ZUser contributionsMediaWiki 1.35.6https://criu.org/index.php?title=Pidfd&diff=5580Pidfd2025-01-04T18:52:55Z<p>Bsach64: </p>
<hr />
<div>This article describes how we checkpoint/restore pidfds (process file descriptors).<br />
<br />
== Checkpointing ==<br />
All information that we require for restore of pidfds is available in this <code>/proc</code> entry: <code>/proc/$pid/fdinfo/$pidfd</code><br />
<br />
Since CRIU does not support nested pid namespaces, the correct <code>pid</code> to use during restore is the last <code>pid</code> (i.e., <code>pid</code> in the most deeply nested pid namespace) in the <code>/proc/$pid/fdinfo/$pidfd/NSpid</code> field.<br />
So, we only dump that <code>pid</code>.<br />
<br />
== Restoring <code>pidfd(s)</code> Pointing to an Alive Process ==<br />
CRIU, while restoring, first creates all processes in the process tree and then starts opening file descriptors in each process.<br />
<br />
So, If the pidfd points to an alive process, we can simply use <code>pidfd_open()</code> to create the pidfd.<br />
<br />
== Restoring <code>pidfd(s)</code> Pointing to a Dead Process ==<br />
<br />
If the process (to which the pidfd was pointing) is dead, however, we lose access to its pid (<code>/proc/$pid/fdinfo/$pidfd/NSpid</code> becomes -1).<br />
We also cannot open a pidfd pointing to a dead process.<br />
<br />
To overcome these problems, we do the following things:<br />
<br />
We create a <code>hashtable</code> with the <code>inode number</code> of the pidfd acting as the key that stores:<br />
* List of all processes that had a pidfd open with this inode number.<br />
* The highest id in the list of processes (<code>creator_id</code>)<br />
<br />
For each unique <code>inode number</code>, the process with <code>creator_id</code> (let's call it <code>creator</code>) creates a temporary process (let's name this process <code>x</code>).<br />
<br />
The creator process will then open <code>pidfd(s)</code> pointing to <code>x</code> and will send them to all other processes (that had a pidfd with this inode number) using CRIU's <code>send_desc_to_peer</code> and <code>recv_desc_from_peer</code> functions, which allow processes to send and receive file descriptors.<br />
<br />
This way, all processes with pidfds that point to the same dead process remain in the correct state (i.e., have pidfds with the same inode number) even after restoration.<br />
<br />
After the creator process finishes opening and sending all pidfds, it kills the temporary process <code>x</code>.<br />
<br />
== Limitations ==<br />
<br />
* We currently do not support pidfd's opened with the <code>PIDFD_THREAD</code> flag.<br />
* We also cannot C/R pidfd's that point to process(es) outside the current process tree.<br />
<br />
[[Category:Under the hood]]</div>Bsach64https://criu.org/index.php?title=Pidfd&diff=5579Pidfd2025-01-04T18:52:06Z<p>Bsach64: Created page with "This article describes how we checkpoint/restore pidfds (process file descriptors). == Checkpointing == All information that we require for restore of pidfds is available in..."</p>
<hr />
<div>This article describes how we checkpoint/restore pidfds (process file descriptors).<br />
<br />
== Checkpointing ==<br />
All information that we require for restore of pidfds is available in this <code>/proc</code> entry: <code>/proc/$pid/fdinfo/$pidfd</code><br />
<br />
Since CRIU does not support nested pid namespaces, the correct <code>pid</code> to use during restore is the last <code>pid</code> (i.e., <code>pid</code> in the most deeply nested pid namespace) in the <code>/proc/$pid/fdinfo/$pidfd/NSpid</code> field.<br />
So, we only dump that <code>pid</code>.<br />
<br />
== Restoring <code>pidfd(s)</code> Pointing to an Alive Process ==<br />
CRIU, while restoring, first creates all processes in the process tree and then starts opening file descriptors in each process.<br />
<br />
So, If the pidfd points to an alive process, we can simply use <code>pidfd_open()</code> to create the pidfd.<br />
<br />
== Restoring <code>pidfd(s)</code> Pointing to a Dead Process ==<br />
<br />
If the process (to which the pidfd was pointing) is dead, however, we lose access to its pid (<code>/proc/$pid/fdinfo/$pidfd/NSpid</code> becomes -1).<br />
We also cannot open a pidfd pointing to a dead process.<br />
<br />
To overcome these problems, we do the following things:<br />
<br />
We create a <code>hashtable</code> with the <code>inode number</code> of the pidfd acting as the key that stores:<br />
* List of all processes that had a pidfd open with this inode number.<br />
* The highest id in the list of processes (<code>creator_id</code>)<br />
<br />
For each unique <code>inode number</code>, the process with <code>creator_id</code> (let's call it <code>creator</code>) creates a temporary process (let's name this process <code>x</code>).<br />
<br />
The creator process will then open <code>pidfd(s)</code> pointing to <code>x</code> and will send them to all other processes (that had a pidfd with this inode number) using CRIU's <code>send_desc_to_peer</code> and <code>recv_desc_from_peer</code> functions, which allow processes to send and receive file descriptors.<br />
<br />
This way, all processes with pidfds that point to the same dead process remain in the correct state (i.e., have pidfds with the same inode number) even after restoration.<br />
<br />
After the creator process finishes opening and sending all pidfds, it kills the temporary process <code>x</code>.<br />
<br />
== Limitations ==<br />
<br />
* We currently do not support pidfd's opened with the <code>PIDFD_THREAD</code> flag.<br />
* We also cannot C/R pidfd's that point to process(es) outside the current process tree.</div>Bsach64