mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-07-21 01:06:58 +00:00
5d5e8b801c
Restorer does really restore shared memory (including page contents restore) only on master process, while all other processes do open such memory area via map_files/ procfs entry so that we might have a situation when shared VMA is present in some particular core-%d.img file but it's not listed in collected shmems array and find_shmem_by_pid will return NULL. This is perfectly fine, be ready for that. Another issue is that shared memory might look like CR_FD_SHMEM: /home/cyrill/projects/kernel/crtools/shmem-2641.img ---------------------------------------- 0x7f2200775000-0x7f2200776000 id 19664 0x7f2200776000-0x7f2200777000 id 19663 ---------------------------------------- So vma area is [x;y) range and we should distinguish two shmem lookup cases - one when we search for page in shmem area - second when we lookup shmem area in collected ranges They both have a different lookup conditions so single find_shmem splitted into two helpers find_shmem and find_shmem_page as appropriate. This patch finally fixes the three process asynchronious shared memory updates test-case. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> |
||
|---|---|---|
| .. | ||
| atomic.h | ||
| bitops.h | ||
| compiler.h | ||
| crtools.h | ||
| image.h | ||
| libnetlink.h | ||
| list.h | ||
| lock.h | ||
| log.h | ||
| parasite-syscall.h | ||
| parasite.h | ||
| ptrace.h | ||
| restorer.h | ||
| sockets.h | ||
| syscall-codes.h | ||
| syscall.h | ||
| types.h | ||
| unix_diag.h | ||
| util.h | ||