How it works now
Dumping
Currently memory dumping depends on 3 big technologies:
- /proc/pid/smaps file and /proc/pid/map_files/ directory with links are used to determine
- memory areas in use by task
- file is mapped (if any)
- shared memory "identifier" to resolve the MAP_SHARED areas
- /proc/pid/pagemap file that reveals important flags
- present indicates that the physical page is there. Non-present pages are not dumped.
- anonymoys for the MAP_FILE | MAP_PRIVATE mapping indicate that the page in question is already COW-ed from the file's. Not-anonymous pages are not dumped as they are still in sync with the file
- soft-dirty bit is used by memory changes tracking
- Ptrace SEIZE that is used to grab pages from task's VM into pipe (with vmsplice)
Restoring
This one depends only on the /proc/pid/map_files/ to restore the shmem regions -- tasks just open some other's link and map it to create shmem region. The pages restoration just writes page data "in place".
Non linear mappings
Currently we don't support non-linear mappings (fail dump if present)