2,257
edits
Changes
no edit summary
== How CRIU gets the information to dump ==
== How CRIU gets the information to dump ==
So on dump CRIU needs to find out several things.
# The FD numbers owned by tasks
# How File-s are shared between tasks' FDTs
# What Inode types are there
# State of File and Inode objects
=== FD numbers ===
This is simple. Reading the ''/proc/$pid/fd'' or ''/proc/$pid/fdinfo'' directory just shows the required numbers.
=== Files sharing ===
In order to find out whether two Files sitting beyond two FDs of two tasks are the same CRIU uses the <code>kcmp</code> system call.
=== Determining Inode type ===
The inode type in most of the cases can be found out by <code>stat()</code>-ing the descriptor. To do this CRIU asks the [[parasite code]] to send back the files via unix socket's <code>SCM_RIGHTS</code> message. After this, having the same Files at hands CRIU <code>fstat</code>s each and checks the <code>st_mode</code> field.
For some stupid files (signalfd, inotify, etc.) the mode field is zero and CRIU reads the ''/proc/$pid/fd/$fd/'' link. For those the link target uniquely defines the Inode type.
=== State of File and Inode ===
From File CRIU needs only two things -- the mode and the position. Both can be read from ''/proc/$pid/fdinfo/$fd/'' and the latter one can be requested via <code>lseek</code> call.
Getting the Inode state is specific to Inode. CRIU uses the following sources of information:
# Date from ''/proc/$pid/fdinfo/$fd/''
# Link target of ''/proc/$pid/fd/$fd/'' link
# Inode-specific ioctl()-s
# read/recv/tee-s to fetch data from descriptor (pipe data, socket queues)
# sock_diag info to get info about sockets
[[Category:Under the hood]]