This is what we have:
> compel/src/lib/infect.c:1145:38: error: taking address of packed member
> 'uc_sigmask' of class or structure 'ucontext_ia32' may result in an
> unaligned pointer value [-Werror,-Waddress-of-packed-member]
>         blk_sigset = RT_SIGFRAME_UC_SIGMASK(f);
>                      ~~~~~~~~~~~~~~~~~~~~~~~^~
> compel/include/uapi/asm/sigframe.h:133:4: note: expanded from macro
> 'RT_SIGFRAME_UC_SIGMASK'
>         (&rt_sigframe->compat.uc.uc_sigmask))
>           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 error generated.

Indeed this results in an unaligned pointer, but as this is intended and
well known (see commit dd6736bd "compel/x86/compat: pack ucontext_ia32"),
we need to silence the warning here.

For more details, see https://reviews.llvm.org/D20561

Originally found by Travis on Alpine Linux, reproduced on Ubuntu 17.10.

[v2: fix for non-x86]
Reported-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

For older kernels (e.g. RHEL7 with 3.10) it seems that wait(NULL) after
ptrace(PTHREAD_ATTACH) does not work properly for threads that have
to be created via clone().

Fix this by using waitpid() with the __WALL flag.

>From the waitpid() man page:

 __WALL (since Linux 2.4)
 Wait  for  all  children, regardless of type ("clone" or "non-clone").
Reported-by: Adrian Reber <areber@redhat.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Plus patch replaces atoi(32 bit) to xatol(64 bits) for "pipe_ino" mount
option thus fixing the issue with negative inode number for big values.

v2: fixed uninitialized "err" variable in "parse_options" function
Signed-off-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

These helpers are safe versions of atol() and atoi() respectively.
And they check for overflow and NAN errors

v3:
1) Added string print to convertion error message in xatol_base()
2) Added check for INT range in xatoi()
Signed-off-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

==36==ERROR: AddressSanitizer: heap-buffer-overflow on address
	0x60200000001c at pc 0x7fb26c88d5f9 bp 0x7ffc15087d40 sp 0x7ffc150874d0
WRITE of size 13 at 0x60200000001c thread T0
    #0 0x7fb26c88d5f8 in vsprintf (/lib64/libasan.so.4+0x9e5f8)
    #1 0x7fb26c88d986 in __interceptor_sprintf (/lib64/libasan.so.4+0x9e986)
    #2 0x402453 in main /root/git/main/criu/test/zdtm/static/chroot.c:68
    #3 0x7fb26c43e4d9 in __libc_start_main (/lib64/libc.so.6+0x204d9)
    #4 0x4031b9 in _start (/root/git/main/criu/test/zdtm/static/chroot+0x4031b9)
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Without this message, we don't know which fdinfo can't be opened.

https://github.com/xemul/criu/issues/390Signed-off-by: Andrei Vagin <avagin@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

On VZ7 we have a problem in random tests on iptables restore when
running tests in parallel(one iptables-restore instance tries to lock
xtables lock and fails while other instance(some iptables* command) is
already holding the lock):

================== Run zdtm/static/socket_udp_shutdown in ns ===================
Start test
./socket_udp_shutdown --pidfile=socket_udp_shutdown.pid --outfile=socket_udp_shutdown.out
Run criu dump
Run criu restore
=[log]=> dump/zdtm/static/socket_udp_shutdown/77/1/restore.log
------------------------ grep Error ------------------------
(00.158864)      1: 	Running ip rule delete table local
(00.167319)      1: 	Running ip rule restore
(00.175647)      1: 	Running iptables-restore for iptables-restore
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
(00.185245)      1: Error (criu/util.c:719): exited, status=4
(00.185289)      1: Error (criu/net.c:1739): iptables-restore failed
(00.185301)      1: Error (criu/net.c:2382): Can't create net_ns
(00.185370)      1: Error (criu/util.c:1412): Can't wait or bad status: errno=0, status=65280(00.187281) Error (criu/mount.c:2944): mnt: Can't remove the directory /tmp/.criu.mntns.Ai5EG9: No such file or directory
(00.187298) uns: calling exit_usernsd (-1, 1)
(00.187344) uns: daemon calls 0x466a40 (93, -1, 1)
(00.187361) uns: `- daemon exits w/ 0
(00.188375) uns: daemon stopped
(00.188390) Error (criu/cr-restore.c:2450): Restoring FAILED.
------------------------ ERROR OVER ------------------------
Test zdtm/static/socket_udp_shutdown FAIL at CRIU restore

https://ci.openvz.org/job/CRIU/job/CRIU-virtuozzo/job/criu-dev/2873

It happens now in every test-suit run on VZ7 host as we had updated to
1.4.21-18 iptables package, which has patches for xlocks support in
iptables-restore ported:

* Mon Apr 24 2017 Thomas Woerner <twoerner@redhat.com> 1.4.21-18 - Add
support for --wait options to restore commands (RHBZ#1438597)

Whether these patches are ported to other distribution packages we'll
have these problem in other distributions.

Just add -w to wait lock on iptables-restore as older versions does not
error on invalid option, just warning is printed.
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

New ip[6]tables-restore utils has this parameter,
which allows to wait for xtables lock, if it's
occupied. When they don't wait, then the restore
of iptables fails.

Old versions just ignore this parameter
with error in stderr, but it does not make them
fail. So, pass it unconditionally.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

The errors set by both uffdio_copy and uffdio_zeropage are the same and
require the same handling. Let's use a helper function to handle the errors
returned by uffdio_copy and uffdio_zero.
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

When running 'make zdtm' on s390x it fails on RHEL7 with:

 make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
  CC        s390x_regs_check.o
 s390x_regs_check.c: In function "util_hexdump_grp":
 s390x_regs_check.c:214:7: error: "ptr" may be used uninitialized
 in this function [-Werror=maybe-uninitialized]
    ptr += sprintf(ptr, "%02x", buf[i]);

Fix this and assign ptr from the beginning to help gcc.
Reported-by: Adrian Reber <adrian@lisas.de>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Acked-by: Adrian Reber <areber@redhat.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Install the last version of Docker, start a container and C/R it a few times.

The origin idea was to set --empty net for criu dump and criu restore,
but before cde33dcb ("empty-ns: Don't C/R iptables too (v2)"),
criu restore worked without --empty net and we didn't notice that
docker doesn't set this option on restore.

After a small brainstorm, we decided that it is better to remove
this requirement. Docker has to set this option, but with this changes,
the docker issue will be less urgent.

https://github.com/checkpoint-restore/criu/issues/393

So, the long-running task with lazy restore is (almost) finished :) Some
issues are still to be resolved, but the heaviest lift has been done.

Another notable thing is VDSO C/R rework. It's now more robust and fast.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

When merging files into one image we've forgotten about crit x
feature that scans image files by names.

https://github.com/xemul/criu/issues/381

The patch was made for master (as in criu-dev there was problem
with pstree_item.pid parsing), but should apply to dev smoothly.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

When an error occurs we need to close a file descriptor and unmap a region.
Use a separate label for each cleanup.

Fix CID 182644 (#1-2 of 2): Use after close (USE_AFTER_FREE)8. pass_closed_arg:
Passing closed handle f.fd as an argument to bclose
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

It's not really interesting and just pollutes the log
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

The intention was to make sure, that only one packet is sent at a time.
And thus read has to return exactly the size of one packet.

But it doesnt' work as expected, because size of autofs_v5_packet_union
differs on 32 bit and 64 bit architectures.

This is a bug, but it's hidden so deeply, that no one really cares by the
following 2 aspects:

 1) Autofs pipe has O_DIRECT flag, which means excess bytes will be discarded
    upon read.
 2) No one tries to read more than one packet size at a time.

So let's fix the test instead and do not try to read more bytes, than
expected.
Signed-off-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Improve dump_tcp_conn_state() *debugibility*.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

We don't need to look up a mount info element, because
we already have it there.

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

That's a merge conflict between vdso patches set and s390 set.

Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Alice Frosi <alice@linux.vnet.ibm.com>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

We can save some syscalls for *each* dumpee if we don't
open()/seek()/read()/close() /proc/pid/pagemap for each
dumpee and even don't use parasite to parse symtable if
pagemap is unavailable.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

If it does preserve, we can omit checking pagemap for dumpee or
filling symtable in parasite.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Just map vdso at restorer's parking zone, no need for
searching it in CRIU and remap it to park zone.
That will save some open()/read()/close() syscalls
for parsing maps file.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

If there is no vdso in images - we don't need to map it.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Test for previously fixed bugs for vdso-trampolines insertion:
- unmapping original vvar (which went unnoticed)
- leaving rt-vvar after each C/R cycle and resulting pollution
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

No functional change is expected :-D
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

It's hard to stop, when you've begun.
No functional change is expected.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

As rt-vvar can be placed lower (by address) than rt-vdso,
it likely will go earlier in vma_area_list.
That means that at the moment, when we've found rt-vdso,
we already passed rt-vvar and rt_vvar_marked pointer
will not be initialized.

Search for rt-vvar during the second vma list traverse,
so we will always find it if it's present.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

I think, it's better if we still restore the original vvar
as some code may expect vma to be there or may dereference
pointer there.
E.g., if we checkpointed task while it was on vdso page,
it'll dereference pointer to vvar. Better keep it in vmas.

So, the original code deleted it becase it was proxy_vvar_marked,
which I think is misnaming problem.
Having two vvar addresses named rt_ and orig_ describes what to
do with them on dump.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

We need to place @rt_vvar_addr into vdso mark, as we don't know
the position of rt-vvar to be dropped on the following dumps.
I've renamed proxy_*_addr to orig_*_addr, as it looks more
describing.
orig_*_addr we need for marking those VMAs as accordingly,
so restorer would know what to do with them. Otherwise, it'll
think they are just regular vmas.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Previously, arch_prctl(ARCH_MAP_VDSO_32) was only used by
CONFIG_COMPAT to map compatible vdso blob for 32-bit restoree.
But we can make it more generic:
Omitting mremap() for moving vdso to rt-vdso zone in restorer
and afterward on needed position in restoree.
Also omitting reading /proc/self/maps to find vdso/vvar
addresses (to park afterward in restorer).

TLDR; under this kdat feature we can get rid of a buch of mremap()'s
for each restoree and from parsing /proc/self/maps in vdso_init_restore().

The API is present from v4.9 kernel.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Found with fault-injected jump trampolines in vdso,
that on ia32 tests rt-vdso got unmapped.
I've fixed it previously, but have forgot it during
debugging vdso cleanup.

Fixes: commit 8544895a ("ia32/restorer: move 32-bit pie unmap to x86")
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

I'll need to modify it - make it small and ready for changes.
No functional change is expected.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Make it a bit easier to read.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

Make it more readable and change-ready.
No functional change is expected.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

No functional change expected.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>

This is just to split this oversized outgrowed plumped up
parasite_fixup_vdso() and separate it logically.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>