For easier logs-to-constant eyes mapping.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Two writes are slower. This halves the amount of write syscalls
and reduces dump time of a basic container on 5%.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Quite a lot of VMAs in tasks map the same file with different
perms. In that case we may skip opening all these files, but
"borrow" one from the previous VMA parsed.

There's little sense in seeking more that just previous VMA,
as same files are rarely (can be though) mapped in different
locations.

After this on a basic Centos6 container the number of opens and
stats in this function drops from ~1500 to ~500.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Bug was introduced by on-disk-irmap-cache patch. The proc-parse
routine allocates memory for handle, calls ->cb then frees handle.

The problem is that the cb in case of pre-dump saves the handle
for future reference. So, in this future handle's mem happen to
be corrupted.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The vm_socket_id is union with vm_file_fd and calling
close on it is wrong.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It is compared to u64, so should be such as well
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

If we make workdir coincide with images dir, the irmap
cache will be put in parent images for subsequent dump-s.
Try to load it from there.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It's useful to know this value.

W/o cache (first pre-dump) on minimal container the irmap
resolve time is ~0.2 sec. With cache (next pre-dumps or
final dump) on the same container the irmap resolve time
is 10 times less.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

When dumping fsnotifies we may go to irmap to get inode->path
mapping. The irmap engine scans FS (in hinted locations) to
get one and it is slow even though we scan only part of the FS.

Since the above scanning is done while tasks are frozen the
freeze time goes up :(

Improve the situation by generating irmap cache in working dir
at pre-dump when tasks get unfrozen.

The on-disk irmap cache is PB file, it sits in -W directory
and can be loaded on dump/pre-dump start in memory. When
resolving the inode->path mapping irmap may meet these entries,
revalidate them and potentially save time.

After pre-dump the (re-)collected irmap data is written back
to irmap cache image. Typically entries written back are the
same read in on cache load.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We will load some irmap entries in cache from image file,
thus producing potentially stale data in irmap cache. To
handle this, make it possible to mark the entries with
need-revalidation mark and do fstat + numbers comparison
when meeting the entry in cache.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The irmap-cache is PB-file (like the stat-* ones).
See commtns in next patches for more details.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We will generate some info about file-descriptors at that
stage. For now these pre-dumped ones would be fsnotifies,
so the pre-dump of a single fd is written as simple as
possible, but enough for that type of FDs pre-dump.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Well, we want to pre-dump files (fsnotifies), for that we
will need mountinfo-s and root, and for the latter -- the
current ns mask.

The problem with current ns mask is that its generation is
incorporated into ns IDs generation and dumping. And since
the ids dumping is not performed on pre-dump, let's just
provide a helper for ns-mask generation.

Strictly speaking, the whole ns-mask idea is not great, but
it's to be fixed later.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The existing code opens "self" and parses what's in there,
just twist the code a little to accept generic pid.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This works as multi-req thing -- caller issues the
pre-dump request, criu serves it and sends result back.
Then service waits for the next request on the same
session, client doesn't have to re-connect back.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Service shouldn't call client provided scripts, as it
creates a security issue (client may be unpriviledged,
while the service is).

In order to let caller do what it would normally do with
criu-scripts, make criu notify it about scripts. Caller
then do whatever it needs and responds back.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This includes pre-dump and page-server actions and
arguments for memory tracking and page-server.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

After this the called of cr_page_server gets controll
back with the server's pid.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

RPC will start page-server daemon and needs to get the
controll back to report back to caller, but the glibc's
daemon() does exit() in parent context preventing it.

Thus -- introduce own daemonizing routine.

Strictly speaking, this is not pure daemon() clone, as the
parent process has to exit himself. But this is OK for now.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Service will call the pre-dump routine, so this is factoring out
enforcin options for CLI and RPC.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We'll need such further.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Tests fail sometimes, but logs don't contain enough information:
Execute zdtm/live/static/umask00
./umask00 --pidfile=umask00.pid --outfile=umask00.out --mask=0345
make[3]: *** [umask00.pid] Error 1
ERROR: fail to start zdtm/live/static/umask00
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We don't need to wait if a stop signal has been received.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

If someone reads untouched page, the kernel maps the zero page
to this address. This page will not have the SOFT_DIRTY bit and it must
not be dumped.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

When filling fd_parms we do call statfs, no need to call it
again later.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

If we failed to open inode by handle, try doing the irmap
search. If that's successful, dump the "real" path for the
inode.
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

For inotify/fanotifies we cannot always open inodes by a
handle and have to scan directories searching for the inode
path :(

Fortunately, in most of the containers' cases fsnotifies are
put in "typical" places. These are used as hints for scanner.

The best way to go is use openvz's ploop over such filesystems.
Long term solution is to fix NFS to provide opening by handle.
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Some filesystems do not provide open-by-handle functionality. For those,
we should abort fsnotifies dumping, not restoring.

The open_mount() changes are about opening mountpoints inside another
mount namespace.
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

When we can't stat socket name with ENOENT errno this
means, that the socket is bound and unlinked. Don't
drop the whole socket info, just treat it as nameless.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

@vma_area_list::longest is in pages not bytes.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This test fails when run in ns:

(00.300947)      1: Error (util.c:568): exited, status=1
(00.300964)      1: Error (cr-restore.c:1067): 5 exited, status=1
(00.300989)      1: Error (mount.c:637): Can't restore tmpfs content
(00.301005) Error (cr-restore.c:1602): Restoring FAILED.

Reason for failure -- tar is spawned in new mount namespace where
it can not be found (bug #2870).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This test does a few operation in a loop
* create a mapping with random flags
* touch a few pages in a new mapping, if it's writable

This test has two processes. The second process goes a predefined value
of steps behind the first one. When we need to check the result, we stop
the first process, wait until the second process come to the same point
and compare these processes. The processes are dumped in different
states, but at the end both processes must be in the same state.

bash -x test/zdtm.sh -s -i 5 -r transition/maps007
...
(00.743662) Error (page-read.c:107): Missing 139773474525184 in parent pagemap, current iov: base=7f1f8c4cf000,len=4096
(00.743696) Error (page-xfer.c:523): Hole 0x7f1f8c4c5000/4096 not found in parent
(00.744196) Error (mem.c:331): Can't dump page with parasite
(00.758201) Error (cr-dump.c:1828): Dumping FAILED.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

verify decline in size of second parent-level image file
Signed-off-by: Tikhomirov Pavel <snorcht@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

check if size of second parent-level image become smaller
Signed-off-by: Tikhomirov Pavel <snorcht@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>