Changes

The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where criu takes all the information it needs).

The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where criu takes all the information it needs).

Which includes

The information gathered from /proc includes:

* Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo''').

* Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo''').

* etc.

* etc.

The process dumper (lets call it a dumper further) does the following steps during checkpoint stage

The process dumper (called a dumper below) does the following steps during the checkpoint stage.

=== Collect process tree and freeze it ===

=== Collect process tree and freeze it ===

These for are delayed till the last stage for the reasons described further. On this stage CRIU opens files, prepares [[namespaces]], maps (and fills with data) private memory areas, creates sockets, calls chdir() and chroot() and dome some more.

These for are delayed till the last stage for the reasons described further. On this stage CRIU opens files, prepares [[namespaces]], maps (and fills with data) private memory areas, creates sockets, calls chdir() and chroot() and dome some more.

=== Switch to [[restorer context]], restore the rest and continue ===

=== Switch to restorer context, restore the rest and continue ===

The reason for restorer blob is simple. Since criu morphs into the target process, it will have to unmap all its memory and put back the target one. While doing so some code should exist in memory (the code doing the munmap and mmap). So we introduced the restorer blob -- the small piece of code, that doesn't intersect with criu mappings AND target mappings. At the end of stage 2 criu jumps into this blob and restores the memory maps.

The reason for restorer blob is simple. Since criu morphs into the target process, it will have to unmap all its memory and put back the target one. While doing so, some code should exist in memory (the code doing the munmap and mmap). Therefore, the restorer blob is introduced. It's a small piece of code, that doesn't intersect with criu mappings AND target mappings. At the end of stage 2 criu jumps into this blob and restores the memory maps.

At the same place we restore timers not to make them fire too early, here we restore credentials to let criu do priveledged operations (like fork-with-pid) and threads not to make them suffer from sudden memory layout change.

At the same place we restore timers not to make them fire too early, here we restore credentials to let criu do priveledged operations (like fork-with-pid) and threads not to make them suffer from sudden memory layout change.

''See also: [[Tree after restore]]''

''See also: [[restorer context]], [[tree after restore]].''

[[Category:Under the hood]]

[[Category:Under the hood]]