Line 64: |
Line 64: |
| | | |
| == 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]] |