Bsach64 at 18:52, 4 January 2025

2025-01-04T18:52:55Z

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

2025-01-04T18:52:06Z

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

New page

This article describes how we checkpoint/restore pidfds (process file descriptors).

== Checkpointing ==
All information that we require for restore of pidfds is available in this <code>/proc</code> entry: <code>/proc/$pid/fdinfo/$pidfd</code>

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.
So, we only dump that <code>pid</code>.

== Restoring <code>pidfd(s)</code> Pointing to an Alive Process ==
CRIU, while restoring, first creates all processes in the process tree and then starts opening file descriptors in each process.

So, If the pidfd points to an alive process, we can simply use <code>pidfd_open()</code> to create the pidfd.

== Restoring <code>pidfd(s)</code> Pointing to a Dead Process ==

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).
We also cannot open a pidfd pointing to a dead process.

To overcome these problems, we do the following things:

We create a <code>hashtable</code> with the <code>inode number</code> of the pidfd acting as the key that stores:
* List of all processes that had a pidfd open with this inode number.
* The highest id in the list of processes (<code>creator_id</code>)

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

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.

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.

After the creator process finishes opening and sending all pidfds, it kills the temporary process <code>x</code>.

== Limitations ==

* We currently do not support pidfd's opened with the <code>PIDFD_THREAD</code> flag.
* We also cannot C/R pidfd's that point to process(es) outside the current process tree.

← Older revision		Revision as of 18:52, 4 January 2025
Line 35:		Line 35:
	* We currently do not support pidfd's opened with the <code>PIDFD_THREAD</code> flag.		* We currently do not support pidfd's opened with the <code>PIDFD_THREAD</code> flag.
	* We also cannot C/R pidfd's that point to process(es) outside the current process tree.		* We also cannot C/R pidfd's that point to process(es) outside the current process tree.
		+
		+	[[Category:Under the hood]]

Pidfd - Revision history

Bsach64 at 18:52, 4 January 2025

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