The restore_switch_stage() already waits tasks at the
end, so there's no need in one more waiting.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
It is used now to close descriptors of mount namespaces
and will be used for network namespaces too.
Acked-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
It is required for cases when we inject a fault in criu restore.
In this case we execute "criu restore" and check that it fails,
then we execute "criu restore" without a fault and check that it passes.
If the first "criu restore" restores only a part of processes,
the second criu can get PID of one of restored processes.
https://github.com/xemul/criu/issues/282
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
We need compat realization for restorer unmap as after rt_sigreturn()
the task is stopped it 32-bit code and ptrace API doesn't allow
setting x86_64 full registers set to ia32 task.
Generic restorer has now x86-specific __export_unmap_compat()
function, which isn't right.
Clean restorer from x86-related realization.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
We don't need __export_unmap_compat() for !CONFIG_COMPAT in restorer
blob. This preparation will allow to move compatible unmap that's
written in x86 asm from generic restorer blob to arch/x86.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Each `make tags` resulted in running feature-tests.
That's not needed for tags generation.
Don't waste time on tests as we don't compile anything.
Reported-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Let's pretend that we're doing something ;-D
FWIW: cleaning two lines in the test output:
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
========================== Run zdtm/static/tty03 in h ==========================
make[2]: Nothing to be done for `default'.
Start test
make[2]: Nothing to be done for `default'.
./tty03 --pidfile=tty03.pid --outfile=tty03.out
Run criu dump
Run criu restore
Send the 15 signal to 24
Wait for zdtm/static/tty03(24) to die for 0.100000
Removing dump/zdtm/static/tty03/24
========================= Test zdtm/static/tty03 PASS ==========================
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Right now they all sit in a separate file. Since we
don't support CLONE_SIGHAND (and don't plan to) it's
much better to have them in core, all the more so
by the time we dump/restore sigacts, the core entry
is at hands already.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
HOSTCFLAGS are populated with CFLAGS if they are set from environment:
CFLAGS=-O1 make
But it turns out that =? operator, which sets variable iff it was unset
previously - is recursive expanded operator.
Which means that value of HOSTCFLAGS is evaluated every time it's used.
Which is wrong with the current flaw in Makefile:
1. it assigns HOSTCFLAGS with CFLAGS from environment as recursive
2. it assigns target-related options to CFLAGS such as -march.
3. HOSTCFLAGS are used (with the current code - here they are expanded
from CFLAGS).
Which results in target-related options supplied to host objects building,
which breaks cross-compilation.
Fix by omitting recursive expansion for HOSTCFLAGS.
Still we need to keep $(WARNINGS) and $(DEFINES) in HOSTCFLAGS.
Link: https://lists.openvz.org/pipermail/criu/2017-April/037109.html
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Reported-by: "Brinkmann, Harald" <Harald.Brinkmann@bst-international.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
DEFINES, LDARCH, VDSO in one place - visually simpler, more terse.
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Arch-specific options will be clearer without support checks.
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
It's defined in NMK - don't redefine it.
Remove BTW twice exports and twice definition of $(LDARCH).
Call 64-bit ARM as aarch64.
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Let's keep the same name for 64-bit ARM platform across source.
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Let's call it aarch64 across all CRIU - as I was confused at least once
with arm64 name in NMK and this arch-support check.
Yet allowed to be named arm64, as NMK patch is separated.
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
I bumped in this myself when I had libc6-dev-i386 installed,
while criu said I didn't. Save other guys'es time, spent
in this place.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
When restoring w/o namespaces it doesn't make sence to
mount /proc by hands and detach it. We can just use the
host-side one.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
When injecting the restorer blob criu parses /proc/self/maps
file to find out the hole for the blob itself. It happens
every time and the maps file for criu is now HUGE (~12k),
so it's much more efficient to use bfd for it rather than
glibc's fopen.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
This file is parsed on each start, it's nicer to make it
use bfd engine and save several syscalls and #PFs.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
When running criu_dump() with zero pid (self dump) a zombie
from the library is left underneath the running processes
and this zombie is thus written into the images.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
This naming is left from the first compatible kernel patches.
At that time to return to 32-bit task rt_sigreturn was used with
a special flag.
Now it's not true anymore, the naming doesn't relate.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Many of sysctl_op-s we have read (or write) single entry.
In current implementaiton this results in two opens and
two closes for each -- open /proc/sys, then open the rest.
It's better to use open_proc() as the latter already have
fd for /proc cached.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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>
As cr-exec is deprecated-removed, drop ruins.
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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/287
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
