- 10 May, 2017 8 commits
-
-
Dmitry Safonov authored
Point that ia32 C/R was disabled due to missed packages. Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
As cr-exec is deprecated-removed, drop ruins. Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Each opening of a file results in getpid() call which is now a pure syscall :( For this particular case this value is poitless, as log engine already prints pids. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
We do this to get real pids of the threads, but sometimes we just know that value. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Veronika Kabatova authored
Introducing negative options for true / false values. The original getopt_long parser is kept since it is able to set flag-like values (instead of setting these values in the switch when it's not needed). The type of the options needed to be changed to integers for getopt_long to accept flag-like value settings (as per getopt_long documentation, the address of integer variable has to be passed). Corresponding negative options are not added for deprecated options. This patch is a preparation for the addition of configuration files (GitHub issue #278). General idea of this feature is to have global configuration files in /etc/criu.d/ directory and user-specific configuration files in $HOME/.criu.d/ directory, with the possibility of specifying a chosen file to be used (default files will be used if none is specified, or none in case the default ones are not present, to not break compatibility). The options in configuration files should be possible to be overriden by the options specified on command line, hence the negative options addition. The whole feature of configuration files will remove the need of specifying all the options on command line, with the possibility of reusing a file for different use case with only overriding some of the values specified there. In case both types of option (negative and positive) are passed, the later one will be applied -- this works with the philosophy of overriding the "earlier" options from configuration files. Changes since v1: - Describe the --no- option prefix in the beginning of OPTIONS section in both man page and --help instead of mentioning it at every eligible line (this also fixes line length issue with --help) - Fix the accidental removal of check_only case caused by bad rebase - Use a macro for getopt_long struct option generating instead of additional defines and hardcoded lines Signed-off-by:
Veronika Kabatova <vkabatov@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Mike Rapoport authored
Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
When checking for XSAVE availability it makes more sense to check for OSXSAVE than to check for XSAVE. This way the check works on systems booted with the 'noxsave' kernel command-line. travis-ci: success for zdtm/static/fpu01: check for OSXSAVE instead of XSAVE Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
-
Kirill Tkhai authored
Make this function more generic: we want to do not dup not only transport socket of parent, but just all service fds, which were not opened at the moment of clone() in parent. But, yes, currently it's only transport socket. travis-ci: success for files: Unify clone_service_fd() Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
-
- 24 Apr, 2017 1 commit
-
-
Pavel Emelyanov authored
So, we've done a HUUGE rework in this release, that's why it's 3.0. Two biggest changes are: * Compel library -- the framwork for parasite code injection. * 32bit x86 support. Note, that it's neither x32 support, not 32-bit criu. It's purely the ability to dump 32-bit tasks on 64-bit host. With compel at hands the 'criu exec' is removed. Main set of kudos go to Cyrill and Dima for this heavy lifting :) Other things include shutdown-ed UDP sockets, bind-mounts to external bind mounts, ASAN, extentions to RPC, rework of SysVIPC shmem dump format and some bugfixes and beautifications in CRIT. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
-
- 20 Apr, 2017 3 commits
-
-
Dmitry Safonov authored
As for compiling syscalls.S needed syscall-aux.h header, which is linked with making $(sys-asm-types), add it to deps. Fixes: > In file included from compel/arch/aarch64/plugins/std/syscalls/syscalls.S:2:0: > compel/include/uapi/compel/plugins/std/syscall-codes.h:568:44: fatal error: compel/plugins/std/syscall-aux.h: No such file or directory > #include <compel/plugins/std/syscall-aux.h> > ^ > compilation terminated. Cc: Pavel Emelyanov <xemul@virtuozzo.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
As helper unmaps 64-bit vDSO blob, it can call only raw syscalls. Also by that reason it's code should be not instrumented with GCOV/ASAN. Disable instrumentation by separating it into new object and filtering gcov/asan cflags. Fixes: #290 @avagin, it rarely reproduces, I failed to reproduce even once (with gcov, on the same env00 test, with the same linux-next) please, reopen #290 if you'll spot it afterward. Reported-by:
Andrei Vagin <avagin@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Fixes compile-time errors on Fedora like: In file included from unlink_fstat01.c:9:0: > unlink_fstat01.c: In function ‘main’: > ../lib/zdtmtst.h:123:11: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘__off64_t {aka long long int}’ [-Werror=format=] > test_msg("FAIL: %s:%d: " format " (errno = %d (%s))\n", \ Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
- 17 Apr, 2017 5 commits
-
-
Dmitry Safonov authored
Please, see incode comment about the issue. There was an attempt to fix this feature in kernel: http://www.spinics.net/lists/arm-kernel/msg258870.html I'll send a patch for kernel with a correct justification. Still it's worth to workaround this on older kernels. mremap() after shmat() makes it possible to C/R shmem between ARMv7 CPUs. Without it C/R will fail even on the same platform. That is possible that this workaround changes *restore failure* to *corruption* in shared memory after restore. Still, I think it's worth to be applied by the following reasons: 1. All ARMv7 CPUs do not have VIPT aliasing data cache. And ARMv6 CPUs may have any, but they are not popular because of UMP. 2. SysV IPC shmem should be writable and SHMLBA unaligned (if it's only readable, then it's OK). 3. For the data corruption we need to migrate from non-VIPT cached CPUs to VIPT aliasing. 4. As this is shmem migration between platforms - quite likely we have it`s copy (in case of whole IPC namespace dump - in images). 5. C/R before on the same CPU may fail (quite likely, more than 50% of zdtm/transition/ipc failed while I've test it). So, I think it's very unlikely that someone uses CRIU to migrate from ARMv7 to ARMv6 unaligned writable shmem, but if he is - here is a BIG WARNING on restore. And after all: we've restored application as it was on checkpoint, we can't reliably tell that shmem needs align on the target platform, but we warned on restoring. I wanted to test the cpuid for VIPT caching firstly, but it's in cp15 coprocessor, which means it's unavailable from userspace. Only one reliable way to tell is to check couple of first boot lines in dmesg: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Flag `noexecstack' for ld implies `EXSTACK_DISABLE_X' ELF flag on CRIU binary. Without this flag the kernel ELF loader will set `READ_IMPLIES_EXEC' personality bit: > if (elf_read_implies_exec(loc->elf_ex, executable_stack)) > current->personality |= READ_IMPLIES_EXEC; This flag is checked by sys_mmap(): > if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC)) > if (!(file && path_noexec(&file->f_path))) > prot |= PROT_EXEC; Which results in each mmap() syscall returning +x mapping for any readable mapping for CRIU binary, e.g: Before C/R: 76fc4000-76fc5000 r--p 0001f000 b3:02 131656 /usr/lib/ld-2.25.so 76fc5000-76fc6000 rw-p 00020000 b3:02 131656 /usr/lib/ld-2.25.so After restore: 76fc4000-76fc5000 r-xp 0001f000 b3:02 131656 /usr/lib/ld-2.25.so 76fc5000-76fc6000 rwxp 00020000 b3:02 131656 /usr/lib/ld-2.25.so Which also makes ZDTM very sad: 1: Old maps lost: set(["76f80000-76f81000 ['rw-p', '0120400']", "25000-26000 ['rw-p', '0120400']", "76f7d000-76f7f000 ['rw-p']", "14a8000-14c9000 ['rw-p']", "76f4a000-76f4c000 ['r--p', '0120400']", "7ed3d000-7ed7f000 ['rw-p']", "76f7f000-76f80000 ['r--p', '0120400']", "24000-25000 ['r--p', '0120400']", "76f4c000-76f50000 ['rw-p', '0120400']"]) 1: New maps appeared: set(["76f7f000-76f80000 ['r-xp', '0120400']", "7ed3d000-7ed7f000 ['rwxp']", "76f4a000-76f4c000 ['r-xp', '0120400']", "76f80000-76f81000 ['rwxp', '0120400']", "24000-25000 ['r-xp', '0120400']", "14a8000-14c9000 ['rwxp']", "25000-26000 ['rwxp', '0120400']", "76f7d000-76f7f000 ['rwxp']", "76f4c000-76f50000 ['rwxp', '0120400']"]) Maybe we also need to set it for arm64 or even for all archs, but that needs to be tested in the first place, so add it now to arm32, x86 already has it. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
On some distro the default python interpreter is Python 3, which results in such errors: > Running zdtm/static/socket-tcp-closed.hook(--post-start) > make[1]: Nothing to be done for default. > ./socket-tcp-closed --pidfile=socket-tcp-closed.pid --outfile=socket-tcp-closed.out > File "zdtm/static/socket-tcp-closed.hook", line 16 > except OSError, e: > ^ > SyntaxError: invalid syntax > ######### Test zdtm/static/socket-tcp-closed FAIL at hook --post-start ######### > Running zdtm/static/socket-tcp-closed.hook(--clean) > File "zdtm/static/socket-tcp-closed.hook", line 16 > except OSError, e: > ^ > SyntaxError: invalid syntax > Traceback (most recent call last): > File "zdtm.py", line 1921, in <module> > do_run_test(tinfo[0], tinfo[1], tinfo[2], tinfo[3]) > File "zdtm.py", line 1388, in do_run_test > try_run_hook(t, ["--clean"]) > File "zdtm.py", line 1053, in try_run_hook > raise test_fail_exc("hook " + " ".join(args)) > __main__.test_fail_exc: <__main__.test_fail_exc instance at 0x76294468> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
[criu]# git status -s ?? compel/arch/arm/plugins/std/syscalls/syscalls.S ?? compel/plugins/include/uapi/std/syscall-aux.S ?? compel/plugins/include/uapi/std/syscall-aux.h Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Arm32 devices often have poor amount of RAM. E.g., RPI2 board has only 1Gb memory. This lead to failures with maps01 test, which tries to mmap() 1Gb of memory. The failures of test is not very evident - let's document mmap() errors here to blow some light on the situation. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
- 11 Apr, 2017 18 commits
-
-
Pavel Emelyanov authored
Unix socket name can be a string with any bytes in it. So to print the name we use base64 encoding. Doing so doesn't allow to see the socket name when it contains only printable chars. So here's the custom encoding for bytes fields, that can be used for custom conversion. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
There are several places in image files, where we store integers, but these numbers actually mean some string. E.g. socket families, states and types and tasks states. So here's the (criu).dict option for such fields that helps to convert the numbers into strings and back. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
Instead of parsing the output of 'criu -V' this offers a RPC interface to get CRIU's version. In a follow up patch a test script is included to use the new interface: ./version.py Connecting to CRIU in swrk mode to check the version: RPC: Success CRIU major 2 CRIU minor 12 CRIU gitid v2.12-635-g6d3ae4d This change exports the following version fields: * major * minor * gitid (optional) * sublevel (optional) * extra (optional) * name (optional) The optional gitid field is not set when CRIU is not built from git. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
This script connects to 'criu swrk' and asks for the version. If running from a git checkout the output would look like this: $ ./version.py Connecting to CRIU in swrk mode to check the version: RPC: Success CRIU major 2 CRIU minor 12 CRIU gitid v2.12-635-g6d3ae4d If not running from git checkout it looks like this: $ ./version.py Connecting to CRIU in swrk mode to check the version: RPC: Success CRIU major 2 CRIU minor 12 If running with a CRIU binary which does not support the VERSION command: $ ./version.py Connecting to CRIU in swrk mode to check the version: Error (cr-service.c:116): RPC error: Invalid req: Success RPC: Unexpected msg type Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Right now the contents of the sysvipc shmem segment is stored as raw blob in the ipcns-shm image. This is bad for two reasons. First is that huge segments with holes are filled with real zeroes in image. Second is that we prefer not to mix images with pb object and raw data. To fix both let's re-use the shmem.c code that keeps anon shared memory contents in pagemap/pages images. https://github.com/xemul/criu/issues/287Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
After the commit 02c763939c10 ("test/zdtm: unify common code") CFLAGS with -D_GNU_SOURCE defined in the top Makefile are being passed to tests Makefiles. As _GNU_SOURCE is also defined by tests, that resulted in zdtm tests build failures: make[2]: Entering directory `/home/criu/test/zdtm/lib' CC test.o test.c:1:0: error: "_GNU_SOURCE" redefined [-Werror] #define _GNU_SOURCE ^ <command-line>:0:0: note: this is the location of the previous definition cc1: all warnings being treated as errors make[2]: *** [test.o] Error 1 However, we didn't catch this in time by Travis-CI, as zdtm.py doesn't do `make zdtm`, rather it does `make -C test/zdtm/{lib,static,transition}`. By calling middle makefile this way, it doesn't have _GNU_SOURCE in CFLAGS from top-Makefile. I think the right thing to do here - is following CRIU's way: rely on definition of _GNU_SOURCE by Makefiles. This patch is almost fully generated with find test/zdtm/ -name '*.c' -type f \ -exec sed -i '/define _GNU_SOURCE/{n;/^$/d;}' '{}' \; \ -exec sed -i '/define _GNU_SOURCE/d' '{}' \; With an exception for adding -D_GNU_SOURCE in tests Makefile.inc for keeping the same behaviour for zdtm.py. Also changed utsname.c to use utsname::domainname, rather private utsname::__domainname, as now it's uncovered (from sys/utsname.h): > struct utsname > { ... > # ifdef __USE_GNU > char domainname[_UTSNAME_DOMAIN_LENGTH]; > # else > char __domainname[_UTSNAME_DOMAIN_LENGTH]; > # endif Reported-by:
Adrian Reber <areber@redhat.com> Cc: Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
v2: Use the devicemapper storage driver for docker containers to run more tests. AUFS doesn't support file handles, so a few tests (e.g. inotify00 can't be run). Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
v2: Use logerr where needed. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
An abstract name can contain zero characters. Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
In this patch, we replace all zero characters to '@'. ==30==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e3ca at pc 0x7f34144b6be1 bp 0x7ffee7b6bb20 sp 0x7ffee7b6b298 READ of size 26 at 0x60300000e3ca thread T0 #0 0x7f34144b6be0 (/lib64/libasan.so.3+0x8dbe0) #1 0x7f34144b8e4d in __interceptor_vsnprintf (/lib64/libasan.so.3+0x8fe4d) #2 0x4966cb in vprint_on_level criu/log.c:228 #3 0x496b64 in print_on_level criu/log.c:249 #4 0x505c94 in collect_one_unixsk criu/sk-unix.c:1401 #5 0x4e7ae3 in collect_image criu/protobuf.c:213 #6 0x462c5c in root_prepare_shared criu/cr-restore.c:247 #7 0x462c5c in restore_task_with_children criu/cr-restore.c:1420 #8 0x7f34132d70ec in __clone (/lib64/libc.so.6+0x1030ec) 0x60300000e3ca is located 0 bytes to the right of 26-byte region [0x60300000e3b0,0x60300000e3ca) allocated by thread T0 here: #0 0x7f34144efe70 in malloc (/lib64/libasan.so.3+0xc6e70) #1 0x7f3413bdb021 (/lib64/libprotobuf-c.so.1+0x6021) Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Using open_proc/fopen_proc/__open_proc is better since - it uses openat - it comes with nice error reporting Let's use it in places where we can. Even if it does not give any improvements (such as in cr-check.c), error message unification is good enough reason to do so. Requested-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Replace 8-spaces with a tab in code. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
So, in places where we have errno available (and it makes sense to show it), we want to use pr_perror(). In places where errno is not set/used, use pr_err(). Cc: Dengguangxing <dengguangxing@huawei.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
1. No newline (pr_perror() already adds one for you) 2. No colon before file name, e.g. WAS: Can't open file: /some/file: permission denied NOW: Can't open file /some/file: permission denied Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Dengguangxing <dengguangxing@huawei.com> Reviewed-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Unlike pr_perror(), pr_err() does not append a newline. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
- 02 Apr, 2017 5 commits
-
-
Andrei Vagin authored
It's very hard to understand an error without a context Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
The contents of sysvshm areas is sometimes dumped twice. First time it goes via cr_dump_shmem(), since each attachment of the segment is noted by the add_shmem_area() and thus gets into the list scanned by the former call(). Second time it is dumped by dump_ipc_shm_pages(). Another thing is that in the 1st dump memory gets into the standard pagemap/pages image pair, while in the 2nd time it's all written as plain byte array into ipcns-shm.img. At restore contents is read from the ipcns-shm.img (2nd). While the first way is preferred, let's (temporarily) eliminate it. Historically these segments were dumped and restored the 2nd way. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
This is just to prevent a compiler warning. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
When this test is compiled on ARMv7, we get this: > maps03.c: In function 'main': > maps03.c:15:31: error: result of '10l << 30' requires 35 bits > to represent, but 'long int' only has 32 bits [-Werror=shift-overflow=] > mem = (void *)mmap(NULL, (10L << 30), PROT_READ | PROT_WRITE, > ^~ Surely, the nature of the test looks like it needs 64-bit addressing. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-