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

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

As we've added work_dir_fd to RPC, lets add support for it to libcriu.
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

otherwise it won't compile:

util.c: In function ‘cr_daemon’:
util.c:594:8: error: ignoring return value of ‘chdir’, declared
with attribute warn_unused_result [-Werror=unused-result]
   chdir("/");
        ^
Signed-off-by: Tikhomirov Pavel <snorcht@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We errorneously report nr_compared as total number of restored pages.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

If we've found zero VMAs in MmEntry try to look for
VMAs in vma-.img image file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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

When writing VMAs we perform too many small writes into vma-.img files.
This can be easily fixed by moving the vma-s into mm-s, all the more
so they cannot be splitted from each other.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We'll merge mm and vma images, so mm should be read in the
same place where vmas are.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

After previous patch is't now possible.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

On restore we will read all VmaEntries in one big MmEntry object,
so to avoif copying them all into vma_areas, make them be pointable.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The plan is to merge vma images into mm ones (see further
patching), so prepare the dumping code for that.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Lost from c8d5f1a2Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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

Currently we check PTRACE_PEEKSIGINFO and if it's defined in a system
header, we suppose that ptrace_peeksiginfo_args is defined there too.

But due to a bug in glibc, this check doesn't work. Now we have F20,
where ptrace_peeksiginfo_args is defined in sys/ptrace and F21 where
it isn't defined.

commit 9341dde4d56ca71b61b47c8b87a06e6d5813ed0e
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Sun Jan 5 16:07:13 2014 -0500

    ptrace.h: add __ prefix to ptrace_peeksiginfo_args
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Right now we do it two times -- on shmem prepare and
on the restore itself. Make collection only once as
we do for fdinfo-s -- root task reads all stuff in and
populates tasks' rst_info with it.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We'll collect VmaEntries early before fork.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

In /proc/<pid>/smaps/ output we may omit testing
for capital hex letters, since we know the format
kernel provides.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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

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

When reading pagemaps, we read it from specific position. To
do it, we called lseek, then read. Fortunetely, there's a
syscall that does both things in one call -- pread. Since
we don't need to keep pagemap's position for further reads,
it perfectly suits our needs.

This removes 75% of lseek calls when dumping basic container.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

When parsing mappings in proc, we fstat vm file, later,
when dumping it, we stat it again to fill fd_parms.
The 2nd stat is not required, we can keep the stat in
vma_area.

This removed 35% of all stat calls on dump of basic container.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The is_foo_link readlinks the lfd to check. This makes
anon-inodes dumping readlink several times to find proper
dump ops. Optimize this thing.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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>