In worst case we might be tryin to proxify vdso zone
when vvar only is remmaped but vdso itself is not yet
(left and right zones shifting). Thus vdso_proxify
will complain that vdso is not yet mapped refusing
to restore.
Thus wait until everything is re-mapped then call
for proxification helper.
Reported: Mr. Jenkins
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In latest linux-next the vdso zone is placed _after_ vvar
zone so eventually we need to handle any combination of
the following cases
- no vvar zone
- vvar before vdso
- vvar after vdso
Here we address all them.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Since we might have a several vDSO zones lets hide
handling in arch-specific routines.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In linux kernel 3.17 most probably the vvar and vdso zones will
be in reverse order, ie vvar first and vdso later so do extended
test for these VMAs coming in one bundle.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
- xfree works well with nil argument no need for additional tests.
- no need for @ret variable, we either success returning 0 explicitly,
either fail with explicit -1
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently we have this:
.......
/* No longer need it */
core_entry__free_unpacked(core, NULL);
ret = prepare_itimers(pid, core, task_args);
if (ret < 0)
goto err;
.......
So we're using ptr right after free-ing it.
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
All mounts is marked as private for one call, so we don't need the
variable private, which has been added in "(55fe0939088d) zdtm: don't
destruct an external mount-namespace"
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
After the commit that walks /proc/self/fd/N path instead of the temporary
one, the add_cgroup() started trimming first several bytes from the cgroup
path.
Test passed, since all cgroups were left as is after dump, so criu restore
didn't recreate them but got EEXIST on all mkdir-s.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
A mount point, which is mounted by someone else, may be umounted in
any moment.
For example the test system executes tests concurrently and sometimes
one test looks up a mount point, which has been mounted by another test.
==================================== ERROR ====================================
Test: zdtm/live/static/inotify00, Namespace: 1
Dump log : /var/lib/jenkins/jobs/CRIU-dump/workspace/test/dump/inotify00/15535/1/dump.log
--------------------------------- grep Error ---------------------------------
(00.021951) Error (cgroup.c:409): cg: failed walking /var/lib/jenkins/jobs/CRIU-dump/workspace/test/dump/signalfd00/15538/1/.criu.cgmounts.UGj28v/ for empty cgroups
(00.021967) Error (cr-dump.c:1601): Dump core (pid: 15535) failed with -1
(00.025509) Error (cr-dump.c:1914): Dumping FAILED.
------------------------------------- END -------------------------------------
================================= ERROR OVER =================================
In the previous patch I suggested to open a mount point, but it brought
other problems. We may open a directory where a cgroup mount has been
umounted and an owner will get EBUSY on attempt to remove this
directory.
Reported-by: Jenkins Criuovich
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We have two bugs actually.
First, the check for 'item == root_item' in dump_task_cgroup fires
twice: first when we rite inventory (item == NULL as argument and
root_item == NULL because we haven't yet collected tasks) and the
2nd time when we dump the root task itself.
The 2nd issue sits in dump_cgroups() -- if root_cgset == criu_cgset
we don't write cgroups information at all (checking that we don't
have them with list_is_singular() inside that if). That said, we
don't need to read the cgroups tree if we're not going to dump it.
This patch fixes both.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
In case if something is broken in the kernel and
we get a format corrupted -- simply exit out with
error instead of strlen'ing nil string.
Also while at it -- add a comment about format.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Before we would not detect the mount point for co-mounted controllers. Things
still worked because we'd just re-mount them ourselves and traverse our own
mount point, but this saves an extra mount().
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
No need to pollute typedef out of structure
statement since we don't use it in that form.
Simply typedef in place. And align members
while we're at it.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Was broken by d57be38c -- this one pretty show does return 1.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
This just makes ctl->cur initialized all in one place,
but not scattered all over the code.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Errors building natively for x86_64 on Ubuntu 12.04:
session02.c:142:13: error: ‘PR_SET_CHILD_SUBREAPER’ undeclared
session03.c:175:13: error: ‘PR_SET_CHILD_SUBREAPER’ undeclared
vdso01.c:300: undefined reference to `clock_gettime'
Error cross compiling for arm using Linaro 14.01 toolchain:
gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
cc1: error: unrecognized command line option ‘-mfpu=neon’
cc1: error: unrecognized command line option ‘-marm’
criu-rtc.c:1:0: error: bad value (cortex-a15) for -mtune= switch
cc1: error: unrecognized command line option ‘-mfpu=neon’
cc1: error: unrecognized command line option ‘-marm’
criu-rtc.pb-c.c:1:0: error: bad value (cortex-a15) for -mtune= switch
Errors cross compiling for aarch64 using Linaro 14.01 toolchain:
maps007.c: In function ‘main’:
maps007.c:88:4: error: passing argument 1 of ‘atomic_read’ from incompatible pointer type [-Werror]
if (futex_get(&shm->stop) && atomic_get(&shm->delta) == MAX_DELTA)
^
In file included from ../../lib/lock.h:10:0,
from maps007.c:13:
../../lib/arch/aarch64/include/asm/atomic.h:14:19: note: expected ‘const atomic_t *’ but argument is of type ‘struct f
utex_t *’
static inline int atomic_read(const atomic_t *v)
^
ptrace.c: In function ‘main’:
ptrace.c:97:15: error: ‘PTRACE_GETREGS’ undeclared (first use in this function)
if (ptrace(PTRACE_GETREGS, stopped, NULL, regs)) {
^
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The path in cc->path here always has a "/" prefix since it comes from
/proc/$pid/cgroup. The additional / confuses the string slinging because ftw()
normalizes paths to have one "/" when we start traversing a subdirectory.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When we dive into showing nested message, the call to it will
overwrite the ctl->Arg field with the descriptor of the nested
one. As a result, after the call returns we continue showing
old message with new descriptor.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
We have to many controllers names in cgroup.c file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
During the dump phase, /proc/cgroups is parsed to find co-mounted cgroups.
Then, for each task /proc/self/cgroup is parsed for the cgroups that it is a
member of, and that cgroup is traversed to find any child cgroups which may
also need restoring. Any cgroups not currently mounted will be temporarily
mounted and traversed. All of this information is persisted along with the
original cg_sets, which indicate which cgroups a task is a member of.
On restore, an initial phase creates all the cgroups which were saved. Tasks
are then restored into these cgroups via cg_sets as usual.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If pfn = 0 it means we hit something very strange
condition but better to not yield BUG_ON here,
better exit with error for future investigation.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Cyrill: we exclude these tests because of braindamaged scheme
btrfs uses for subvolume device numbering which we don't
yet support in inrmaps.
Test: zdtm/live/static/inotify_irmap, Result: FAIL
==================================== ERROR ====================================
Test: zdtm/live/static/inotify_irmap, Namespace: 1
Dump log : /mnt/btrfs/workspace/test/dump/inotify_irmap/16077/1/dump.log
--------------------------------- grep Error ---------------------------------
(00.024342) Error (irmap.c:80): irmap: Can't stat /var/spool: No such file or directory
(00.024365) Error (irmap.c:80): irmap: Can't stat /lib/udev: No such file or directory
(00.024378) Error (irmap.c:80): irmap: Can't stat /no-such-path: No such file or directory
(00.024383) Error (fsnotify.c:184): fsnotify: Can't dump that handle
(00.024397) Error (cr-dump.c:1563): Dump files (pid: 16090) failed with -1
(00.024779) Error (cr-dump.c:1911): Dumping FAILED.
------------------------------------- END -------------------------------------
================================= ERROR OVER =================================
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
As per current top commit (9c0c23c0) the amount of code in CRIU
_without_ the contents of the test/ directory is
$ git grep -l . | egrep -v ^test | xargs wc -l
...
49999
This is the only chance for such a great one-liner :)
The place in the code is not completely random -- it's one of the
few occurrences of two consecutive empty lines in a .c file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Tested-by: Andrew Vagin <avagin@parallels.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Ruslan Kuprieiev <kupruser@gmail.com>
