Performance experiments show, that we spend (relatively) a lot of time
mremap-ing areas from premap area into their proper places. This time
depends on the task being restored, but for those with many vmas this
can be up to 20%.

The thing is that premapping is only needed to restore cow pages since
we don't have any API in the kernel to share a page between two or more
anonymous vmas. For non-cowing areas we map mmap() them directly in
place. But for such cases we'll also need to restore the page's contents
also from the pie code.

Doing the whole page-read code from PIE is way too complex (for now), so
the proposal is to optimize the case when we have a single local pagemap
layer. This is what pr.pieok boolean stands for.

v2:
* Fixed ARM compiling (vma addresses formatting)
* Unused tail of premapped area was left in task after restore
* Preadv-ing pages in restorer context worked on corrupted iovs
  due to mistakes in pointer arithmetics
* AIO mapping skipped at premap wasn't mapped in pie
* Growsdown VMAs should sometimes (when they are "guarded" by
  previous VMA and guard page's contents cannot be restored in
  place) be premmaped
* Always premmap for lazy-pages restore
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Next patch will stop premapping some private vmas. In particular -- those,
that are not COW-ed with anyone. To make this work we need to distinguish
vmas that are not cowed with anyone from those cowed with children only.
Currently both have vma->parent pointer set to NULL, so for former let's
introduce the special mark.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Inherited VMAs don't need the descriptor to work with.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Collect VMAs into COW-groups. This is done by checking each pstree_item's
VMA list in parallel with the parent one and finding VMAs that have
chances to get COW pages. The vma->parent pointer is used to tie such
areas together.

v2:
* Reworded comment about pvmas
* Check for both vmas to be private, not only child
* Handle helper tasks
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

We currently keep pointer on parent vma bitmap, but more info
about the parent will be needed soon.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Not all private VMA-s will be premmaped, so a separate sign of
a VMA being on the premap area is needed.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

The page-read will be needed during the premap stage.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

I've met missing vvar on Virtuozzo 7 kernel - just skip
unmapping it.

TODO: check ia32 C/R with kernel CONFIG_VDSO=n
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

I've deleted it previously by the reason that I searched
vdso vma in [vdso/vvar] vma's pair by magic header.
So, I needed to suppress this error.

>From that moment, I've reworked how 32-bit vdso is parsed
and now we don't need to search it, even more: we parse it
only once in the criu helper.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

On x86_64 defconfig it's =m, so if you boot kernel without initramfs
in qemu, you will see this.

[xemul: split long line]

Fixes: #292
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Not needed anymore for CONFIG_COMPAT.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

I was adapting CRIU with ia32 support for building with Koji,
and found that Koji can't build x86_64 packages and have
i686 libs installed.
While at it, I found that i686 libraries requirement is
no longer valid since I've deleted the second parasite.

Drop feature test for i686 libs and put test for gcc.
That will effectively test if gcc can compile 32-bit code
and bug with debian's gcc (#315).
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

I need to add feature test written in assembly to check
if the feature can be compiled.

Add a make function for this purpose.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

After commit 2e8970be "mount: create a mount point
for the root mount namespace in the roots yard", top
of the tree of mount_infos points to the fake mount.
So, when we're looking for appropriate place for
binfmt_misc, we can't find "xxx/proc/sys/fs/binfmt_misc".
Fix that by finding real NS_ROOT manually.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

The routine in question just sets up the mutex to access
/dev/ptmx. This initialization can be done when we collect
a single tty.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

No need to schedule both post-actions, we can merge them. This
also sanitizes the "void *unised" arguments for both.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

This routine just initializes the remap open lock,
and there's already the code that initializes the
whole remap engine.

Re-arrange this part.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Now this lock is only needed to serialize remap open
code, so name it such.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

This routine cleans any file remap.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Ghost remaps allocate path with shmalloc. Add comment
why this is such.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

We used to have users counter on remap which was
incremented each time this routine was called. Nowadays
remaps are managed w/o the refcounting and we no
longer need global mutex protection for it.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

There's no need in separate call to prepare_procfs_remaps().
All remaps are collected one step earlier and we can do
open_remap_dead_process() right at once.

Also rename the latter routine.

✓ travis-ci: success for Sanitize initialization bits
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

This just moves all the deprecated code into one place.

✓ travis-ci: success for Sanitize fsnotify legacy code
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

The lists are only needed to collect marks (deprecated) into
notify objects. The latter ones are stored in fdsec hash, so
for this legacy case we can find them there.

✓ travis-ci: success for Sanitize fsnotify legacy code
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Marks images were merged into regular in 1.3.

✓ travis-ci: success for Sanitize fsnotify legacy code
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Wrong helper is called.

✓ travis-ci: success for Sanitize fsnotify legacy code
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

We only needed it for kernel 3.19. Apparently, Ubuntu 14.04.5 comes
with a kernel from 16.04 (i.e. 4.4), so we can disable this workaround!

Anyway, just in case, let's do it conditionally.

While at it, slightly improve the comment.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

asciidoc pulls in a lot of dependencies, most of those are not
needed as we just use it to convert txt to a man page. Adding
--no-install-recommended option to apt-get makes it skip those
additional dependencies. The only needed package is xmlto, so
let's add it explicitly.

This results is some 50 packages being skipped (mostly TeX/LaTeX and
some extra SGML tools), wow!
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

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

This reverts commit a8409956, that
got into master by mistake.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Currently we support restoring opened /dev/tty reference
if only control terminal belongs to the same process,
ie no inheritance is allowed.

Thus we should refuse to dump in such scenario
otherwise restore will fail.
Reported-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Currently it is only used to get a file descriptor to the mount
namespace root, but if we have only one mntns, we can open "/".

Cc: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Processes can be restored in another mntns, so mnt_id will be
useless in this case. If mntns isn't dumped, we have to dump a path
to a mount point.

Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

There were kernel bug with 32-bit mmap() returning 64-bit pointer.
The fix is in Torvalds master, will be released in v4.12 kernel.
Checkpointing after v4.9 kernel works good, but restoring will
result in application which will mmap() 64-bit addresses resulting
in segfault/memory corruptions/etc.
As our policy is fail on dump if we can't restore on the same target,
error checkpointing for v4.9.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

The idea is simple. Everyone has to wait its children,
a restore is interrupted if we found abandoned zombie.
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

We currently can batch pagemap entries into page-read list, but will
need to queue them into per-pstree_entry one.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

The pages.img will need to get opened one more time w/o the pagemap.img.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>