Memory dumping and restoring

How it works now

Dumping

Currently memory dumping depends on 3 big technologies:

• /proc/pid/map_files/ directory with links is used to determine
  • which file is mapped
  • shared memory "identifier" to detect the sharing
• mincore() system call says which pages are to be dumped and which are not (to be fixed as well)
• Ptrace SEIZE is used to dump the memory contents

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

Problems

Shared memory dump

When dumping a vma for a task its consents is dumped regardless of whether a mapping is shared. Thus for e.g. 2 tasks with shared region we'll have 2 images with the same contents.

Another problem is that a shared memory region may have different mincore() reports from different tasks. Thus neither of them is suitable for dumping the shmem with current technique.

Mincore report is bad

The existing mincore bit is not enough for several reasons.

1. Swapped out memory is not reported and this is a BUG. Plan is to propose the MINCORE_SWAP bit.
2. File pages are reported as present if they are in page cache regardless of whether they are mapped or not.
3. When a page from private file mapping is not cow-ed (i.e. was read only) it's not necessary to dump it.

Non linear mappings

Currently there's no way to detect this mapping and dump one carefully.