Bug-fix mostly release.
We've also came very close in -dev branch to having x86 32bit
support, so hopefully we'll have it in 2.6/2.7. Lazy restore
now in test-able state, but still we want kernel patches to
leave maintainer's tree, so we still wait.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Currently during criu dump we create link remap in the same dir
where original file was opened. But that dir may not exist during
link remap creation. At the same time it's okay to create link
remap in any dir on the same mount point.
In this patch we do this. We check existance of every dir bottom
up through the original file path. We use the first existing dir.
Similar approach is used on criu restore during ghost file creation.
Signed-off-by: Egor Gorbunov <egor-mailbox@ya.ru>
Signed-off-by: Eugene Batalov <eabatalov89@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
The problem:
$(DEFINES) array added to $(CFLAGS) in a global Makefile.
But, in criu/Makefile we include Makefile.config, which
adds feature-based config options to $(DEFINES).
We need to propagate this new defines again to CFLAGS array.
Previously, I added:
ccflags-y += $(DEFINES)
to Makefile.crtools, but those $(DEFINES) are useful not only
in the crtools makefile.
Let's just propagate this feature defines to CFLAGS and DEFINES
in place.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
- simplify: don't use temporary file -- use /dev/null instead
- return 'true' or 'false' -- this way we can use it inside rules
without external call to bash to compare return with 'y', see
the next patch for a use case.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
'longest' field in vma_area_list struct stores longest private vma
size. It is better to name it priv_longest as it is done
for priv_size field.
Signed-off-by: Fyodor Bocharov <fbocharov@yandex.ru>
Signed-off-by: Eugene Batalov <eabatalov89@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
There can be autofs direct mount point without target mount on top.
In this case there won't be any bindmount and nothing to restore on top of the
autofs mount point.
Signed-off-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
CID 164719 (#1 of 1): Resource leak (RESOURCE_LEAK)
7. leaked_handle: Handle variable sk going out of scope leaks the handle.
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Instead of calling it in fill_fd_params_special (which is called for any found
path).
This reduces amount of system calls on dump.
Signed-off-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Acked-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Two fixes (reported by coverity) and a minor nitpick:
1. Fix checking error from open_proc().
2. Fix buffer overflow. MAX_ULONG can be 20 characters long, so
ret = read() can return 20 and buf[ret] = 0 will overrun the buf.
Make a buf one character longer (an extra byte for \0) and pass
sizeof(buf) - 1 to read to fix it.
3. Call close() right after read().
This is a fixup to commit e68bded.
Reported by Coverity, CID 168505, 168504.
Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Currently, when we use cgroup freezer to seize the tasks we start freezer
and then without waiting the completion of transition procedure we are
seizing tasks read from freezer @tasks file, using fgets.
This is fragile construction because fgets uses internal buffer and tasks
we've read might be exiting same time while we're freezing them,
the kernel won't freeze these exiting tasks because they are dying
anyway and I fear we might read a pid here which is not even in
our cgroup anymore but reused with another out of cgroup task.
Thus lets do the following: use iterations to freeze tasks waiting
for freezer to change its state and then collect/seize all tasks
in one pass.
For example on container I'm playing with it takes just one iteration
| (00.013690) cg: Set 1 is criu one
| (00.013705) freezing processes: 1800000 attempst with 100 ms steps
| (00.013720) freezer.state=THAWED
| (00.013795) freezer.state=FREEZING
| (00.113962) freezer.state=FROZEN
| (00.113990) freezing processes: 1 attempts done
| (00.114073) SEIZE 240893 (comm systemd): success
| (00.114110) Warn (ptrace.c:121): Unable to interrupt task: 240905 (comm kthreadd/1) (Operation not permitted)
| (00.114136) Warn (ptrace.c:121): Unable to interrupt task: 240906 (comm khelper) (Operation not permitted)
| (00.114155) SEIZE 240969 (comm screen): success
| (00.114166) SEIZE 240970 (comm sendmail): success
| (00.114179) SEIZE 240971 (comm sendmail): success
| (00.114189) SEIZE 240972 (comm saslauthd): success
| (00.114202) SEIZE 240973 (comm crond): success
| (00.114211) SEIZE 240974 (comm agetty): success
| (00.114221) SEIZE 240975 (comm agetty): success
| ...
Signed-off-by: Cyrill Gorcunov <gorcunov@virtuozzo.com>
Acked-by: Andrew Vagin <avagin@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
When we're freezing processes we don't count on anything but
rather do 5 attempts with constantly increasing delay.
Lets rather do the following:
- take --timeout option into account (which is 5 seconds
by default) and split it into 100 ms steps;
- when frezing processes check freezer status every 100 ms.
Same time it looks that 5 seconds by default is too small
for high loaded containers. Lets increase it to 10 seconds
by default.
[ skinsbursky@:
Frankly speaking, in this particular case increasing intervals are not nice.
This is not a network issue or something.
Usually freezing takes less than a second, but more, that, say 200ms.
Otherwise it takes quite o lot of time.
If step size is growing all the time, in most of the cases criu will
waste hundreds of milliseconds between iterX (say, third) and (iterX+1)
because of the growing step size.
100ms step looks solid enough: not to small to produce a lot of syscalls
and not to large to waste a lot of time.
With previous scheme freezing was usually taking half a second more that
it should because of this growing step.
[ gorcunov@:
You won't belive, but been able to sepcify --timeout 0 here allowed
me and Stas to catch serieous problem in freezer code.
https://lkml.org/lkml/2016/8/3/317
Without this feature we would have to patch criu instead. So you know,
this would be great to keep it for catching more kernel bugs ;)
Reported-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
This is an unix dgram socket which doesn't have an address and
isn't connected to somewhere, so we can use one socket for all processes.
v2: return non-zero code in error cases
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
These files have to be removed after successful restore.
v2:
Check link remap files only for tests with "--link-remap" option in
descriptor.
Signed-off-by: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Currently if socket() or connect() syscall-s failed, parasite cures itself,
but criu has not got any signals and waits on accept().
This patch adds a futex to synchronize parasite and criu. The server socket
is created with SOCK_NONBLOCK and waits on the futex when a parasite
connects to it, only then criu calls accept() and it returns immediately.
Reported-by: Yohei Kamitsukasa <uhoidx@gmail.com>
Cc: Yohei Kamitsukasa <uhoidx@gmail.com>
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Reviewed-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
We found that sometimes a restored tcp socket doesn't work.
A reason of this bug is incorrect window parameters and in this case
tcp_acceptable_seq() returns tcp_wnd_end(tp) instead of tp->snd_nxt. The
other side drops packets with this seq, because seq is less than
tp->rcv_nxt ( tcp_sequence() ).
We need to restore window parameters to avoid such side effects.
https://github.com/xemul/criu/issues/168
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
It's a new option to get/set window parameters.
v2: don't do this check to unprivileged users, because TCP_REPAIR
is protected by CAP_NET_ADMIN.
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
When using --root option in criu dump, when the mountpoint passed
contains a symbolic link, criu does not resolve its parent correctly.
e.g when passing --root /run/rootfs, dump finishes successfully;
but when /var/run/rootfs is passed, where /var/run is symbolic link to
/run it exits with error "New root and old root are the same".
Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
realloc() may move a memory chunk in case of shrink.
v4: New
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
For `criu exec` we are searching for a place for syscall injection.
While searching for a VMA with PROT_EXEC and with needed size,
we check that VMA is lower than task_size.
The callpath for it is:
cr_exec => parasite_prep_ctl => get_vma_by_ip
Firstly, I thought to omit kdat.task_size checking if it's not inited:
> if (vma_area->e->start >= kdat.task_size && kdat.task_size)
but I think it's a hack then a proper solution.
Besides, this code still can choose VMA over task_size on ARM
and try to inject syscall there (IIRC, ARM has kernel-mapped
VMA in that area).
So, lets init kdat.task_size for `criu exec`.
Also lets init kdat.has_compat_sigreturn so we could exec into
compatible applications.
Cc: Christopher Covington <cov@codeaurora.org>
Cc: Andrew Vagin <avagin@virtuozzo.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Reviewed-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
So, how it was working:
1. build-as was declared with $$(1) and $$(2) which were expanded
on entering the submake;
2. function $(call build-as,...) performed the second expansion of
build-as.
Cons: build-as works only in sub-makefile, no sub-sub-makefile, no
upper/top makefile.
Simplify this by single $(1).
Then build-as variable will be used _only_ in makefile, not in
sub-makefiles.
This is for now fine, as each file, that calls $(MAKE) with
$(build)=dir or $(call build-as,makefile,dir) will include main.mk
from NMK, which has build-as definition (from include.mk).
In the future, we'll get rid of $(build) and $(build-as) workarounds
as finally switch to building from a global makefile.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
It looks like, there is not so much that needs to be fixed for
building criu from a top directory.
After the patch it's possible to do `make criu/mount.o` i.e.
It will build protobuf, compel as dependencies (if they are not built),
but no more from criu objects. If something breaks, you can
do make from vim and jump to error. Nice.
Mostly the patch corrects pathes to objects - I tried to make them
depend on $(obj) or $(SRC_DIR)/criu, where it's possible.
After it tested:
`make -j 10`, `make criu/log.o`, `make clean`, `make mrproper`,
`make install DESTDIR=/tmp/criu`, `make uninstall DESTDIR=/tmp/criu`
Note: I improperly called v1 for this patch as "return to make from
top Makefile" -- but I didn't mean that (and it was friday ;)
This patch doesn't yet switch to top-Makefile building, but that's
a step in that way (building from a top Makefile needs correct pathes
in makefiles) which also adds ability to build objects in subdirectories
and etc.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
For example, if a zombie has a helper that sets up its session id, the
zombie will be reparented to the init task, which will then potentially get
a SIGCHLD for a task which isn't its direct child zombie, which we didn't
handle. Instead, let's find all the zombies for the init task, in case they
get reparented this way.
v2: only the zombies need to be recursively collected, helpers wait on
their children before they exit and will never be reparented
v4: the root task waits all zombies
Reported-by: Tycho Andersen <tycho.andersen@canonical.com>
Cc: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
VDSO_SYMBOL_MAX is max number of symbols, not their max length.
Fixes my buggy commit: 4c69339cd2 ("string.h/pie: use builtin strncmp
instead of strcmp"). Sorry for that bogus misprinting.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
When restoring on a different node, it may happen that pid_max is
below one of the pid we wanted to recreate.
This leads to a restore error when cloning the restarted process:
(00.011172) Forking task with 44794 pid (flags 0x0)
(00.011205) Error (cr-restore.c:1008): 44794: Write 44793 to sys/kernel/ns_last_pid: Invalid argument
This patch computes the largest pid value and sets the kernel pid_max if
necessary.
If the user don't have the permission to do so, the restart is
failing mentioning that we can't push the pid_max limit.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
It looks like, it's completely not needed here.
criu/cgroup.c:582:4: warning: Value stored to 'name' is never read
name = cc->name + 5;
^ ~~~~~~~~~~~~
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
In cr-restore printf() format is mixing "%p" and the prefix "0x" which is
already managed by "%p". This leads to log lines like:
(00.053282) 38744: Found bootstrap VMA hint at: 0x0x100000 (needs ~576K)
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
We masked off SIGCHLD in wait_on_helpers_zombies(), but in fact this is too
late: zombies can die any time after CR_STATE_RESTORE before this function
is called, which lead to us getting "unexpected" deaths. Instead, we should
mask off SIGCHLD before the helpers finish CR_STATE_RESTORE, since they're
explicitly going to wait on all their kids to make sure they don't die
anyway.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
In the next patch, we'll introduce an option to allow for leaving zombie
processes in the pid ns for the test so that we can test the behavior of
zombies. Let's not reap everything after restore, since we'll reap the
restored zombies as well.
v2: restore the old behavior when in reap mode
CC: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
We'll use this variable in the next test to make sure the test suite
doesn't accidentally reap the zombie we want to leave around for the actual
test.
This is kind of ugly and there might be a better way to pass information to
the test's init, I'm open for suggestions :)
CC: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
