- 01 Aug, 2016 40 commits
-
-
Dmitry Safonov authored
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>
-
Tycho Andersen authored
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:
-
Cyrill Gorcunov authored
Seems this snippet escaeped from commit 84bf1ad4 so we may get -EBUSY in open_detach_mount. Signed-off-by:
-
Dmitry Safonov authored
VDSO_SYMBOL_MAX is max number of symbols, not their max length. Fixes my buggy commit: 4c69339c ("string.h/pie: use builtin strncmp instead of strcmp"). Sorry for that bogus misprinting. Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Laurent Dufour authored
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:
-
Mike Rapoport authored
Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
-
Dmitry Safonov authored
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: -
Tycho Andersen authored
Instead of returning, we should revert the cwd as in all the other error paths. *** CID 164720: Resource leaks (RESOURCE_LEAK) /criu/sk-unix.c: 1030 in bind_unix_sk() 1024 goto done; 1025 } 1026 } 1027 1028 if (ui->ue->deleted && unlink((char *)ui->ue->name.data) < 0) { 1029 pr_perror("failed to unlink %s\n", ui->ue->name.data); >>> >>> CID 164720: Resource leaks (RESOURCE_LEAK) >>> >>> Handle variable "cwd_fd" going out of scope leaks the handle. 1030 return -1; 1031 } 1032 } 1033 1034 if (ui->ue->state != TCP_LISTEN) 1035 futex_set_and_wake(&ui->prepared, 1); Signed-off-by: -
Laurent Dufour authored
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:
-
Tycho Andersen authored
Instead, let's skip it before we fork. Signed-off-by:
-
Tycho Andersen authored
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 authored
v2: drop /bin/ps from test deps v3: wait for the zombie to make sure it exits Signed-off-by:
-
Tycho Andersen authored
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 authored
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:
-
Andrew Vagin authored
Signed-off-by:
-
Pavel Emelyanov authored
When fixing mprotected (ro) sysvshmems I used the PROT_EXEC flag to keep the information about whether the segment itself should be rw or ro. This flag leaked to sys_mprotect and some attachments of the segment became executable after restore. Fix this by dropping the EXEC flag. https://github.com/xemul/criu/issues/180Reported-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Andrew Vagin authored
It is always not NULL in sigreturn_restore(). CID 164716 (#1 of 1): Dereference after null check (FORWARD_NULL) 64. var_deref_model: Passing tcore to construct_sigframe, which dereferences null tcore->thread_core. [show details] Signed-off-by:
-
Dmitry Safonov authored
It's generated and cleaned in the top Makefile. Signed-off-by:
-
Dmitry Safonov authored
I think, we can simplify criu's makefile by moving packages checks out to special makefile. Now we only need to make criu's target depend on 'check-packages'. Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Dmitry Safonov authored
Impact: use /dev/null as $(CC) output, drop temporary file. Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Andrew Vagin authored
277 } >>> >>> CID 164718: Memory - corruptions (OVERRUN) >>> >>> Overrunning array "stackbuf" of 2048 bytes at byte offset 2048 using index "ret" (which evaluates to 2048). 278 stackbuf[ret] = '\0'; Signed-off-by:
-
Andrew Vagin authored
267 if (stack < 0) { 268 pr_perror("couldn't log %d's stack", pid); >>> >>> CID 164721: Resource leaks (RESOURCE_LEAK) >>> >>> Variable "f" going out of scope leaks the storage it points to. 269 return -1; Signed-off-by: -
Andrew Vagin authored
Signed-off-by:
-
Andrew Vagin authored
The root yard is used to clean up ghost files. Now try_clean_remaps() is called from depopulate_roots_yard(), so the code about switching mount namespaces was moved to depopulate_roots_yard(). v2: call clean_remaps() when processes are restored in the host mount namespace. Now depopulate_roots_yard() is called from the root task before finishing CR_STATE_FORKING. I moved it to the criu process and do it after clean_remaps(), because clean_remaps() uses the roots yard. It's called after openning all files, because only at this moment we can be sure that all link remap files can be removed. restore_task_with_children() | restore_root_task() ----------------------------------------------------------------------- depopulate_roots_yard() | restore_finish_stage(CR_STATE_FORKING) | prepare_fds() | open_vmas() | | restore_switch_stage(CR_STATE_RESTORE_SIGCHLD) | clean_remaps = 0; If something fails between CR_STATE_FORKING and CR_STATE_RESTORE_SIGCHLD, try_clean_remaps will be called(). try_clean_remaps() try_clean_ghost() rst_get_mnt_root() print_ns_root() snprintf(buf, bs, "%s/%d", mnt_roots, ns->id); it uses mnt_roots, actually it is what we called the roots yard. Signed-off-by: -
Dmitry Safonov authored
It looks like, it's possible that cores for some threads were allocated, but not for all - allocation failed in pstree_alloc_cores(). And after that we will dereference NULL pointer as pstree_free_cores() doesn't check pointer: pstree.c:28:6: warning: Access to field 'tc' results in a dereference of a null pointer (loaded from variable 'core') if (core->tc && core->tc->timers) ^~~~~~~~ Signed-off-by: -
Dmitry Safonov authored
plugin.c:123:3: warning: Potential leak of memory pointed to by 'd' dlclose(h); ^~~~~~~ Signed-off-by: -
Dmitry Safonov authored
path.c:98:2: warning: Value stored to 'len' is never read len -= off; ^ ~~~ path.c:99:2: warning: Value stored to 'path' is never read path += off; ^ ~~~ Signed-off-by: -
Dmitry Safonov authored
There is call to close_page_read on open_pages_image_at failure, also on failure of init_pagemaps. pmes[] is uninitialized here and free_pagemaps() will try to walk them and call xfree(). Which surely would lead to crash. pagemap.c:317:6: warning: Branch condition evaluates to a garbage value if (pr->pmes) ^~~~~~~~ Signed-off-by: -
Dmitry Safonov authored
cr-restore.c:1516:9: warning: Value stored to 'pid' during its initialization is never read pid_t pid = item->pid.real; ^~~ ~~~~~~~~~~~~~~ cr-restore.c:1570:9: warning: Value stored to 'pid' during its initialization is never read pid_t pid = item->pid.real; ^~~ ~~~~~~~~~~~~~~ Signed-off-by: -
Dmitry Safonov authored
... cr-dump.c:515:9: warning: Potential leak of memory pointed to by 'mme.vmas' return ret; ^~~ Signed-off-by: -
Dmitry Safonov authored
Should we like, free them? cgroup.c:890:11: warning: Potential leak of memory pointed to by 'cg.sets' return -1; ^ Signed-off-by: -
Dmitry Safonov authored
There is a bug, that if vsnprintf() wrote nothing to buffer: that may be xstrcat(0, "%s", "") or something like that, than vsnprintf's return value is 0, which will be lesser than delta. The code before would do following: o first cycle: 1. relocate str to new (str is not allocated anymore) 2. vsnprintf() retured 0, delta is greater. o second cycle: 1. relocate previously freed str to new..^C ^C Segmentation fault (core dumped) Weeell, I do think, we can do better job here. Signed-off-by:
-
Andrew Vagin authored
Signed-off-by:
-
Tycho Andersen authored
This is a little bit of a hack. The problem is that we can't actually write this value if memory.use_hierarchy is set, which it is by default. Additionally, we can't do a hack like unsetting memory.use_hierarchy and then writing this, because if the bit is set on the parent, unsetting it will fail. So the restore *can* succeed if things are configured correctly initially, but won't by default, which is annoying for the tests. Plus in the case of systemd, there are child cgroups, so we can't ever unset the root's memroy.use_hierarchy anyway, meaning we could never actually restore correctly. Instead, let's just not try to write the default value, which is probably what everyone is using anyway. Signed-off-by:
-
Tycho Andersen authored
In all kernels, memory.use_hierarchy must be written before there are child cgroups. In 3.11, memory.swappiness must be written before there are child cgroups, so let's consider it a "special" property for all kernels. Signed-off-by:
-
Pavel Tikhomirov authored
and move fs.mqueue.xxx from get_shared_memory_info to get_messages_info Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
-
Pavel Tikhomirov authored
we already have 3/5 fs.mqueue.xxx sysctls so why not have all: /proc/sys/fs/mqueue/msg_default is a read/write file for setting/getting the default number of messages in a queue value if attr parameter of mq_open(2) is NULL. If it exceed msg_max, the default value is initialized msg_max. /proc/sys/fs/mqueue/msgsize_default is a read/write file for setting/getting the default message size value if attr parameter of mq_open(2) is NULL. If it exceed msgsize_max, the default value is initialized msgsize_max. v2: remove check if kernel has sysctls as we do not support such an old kernel(v3.5) Signed-off-by:
-
Andrew Vagin authored
Signed-off-by:
-
Andrew Vagin authored
Signed-off-by:
-
Andrew Vagin authored
Error (arch/x86/crtools.c:83): Failed to get auxval, err: 0 ==2103== Conditional jump or move depends on uninitialised value(s) ==2103== at 0x46F073: seize_wait_task (ptrace.c:238) ==2103== by 0x437592: cr_exec (cr-exec.c:137) ==2103== by 0x41F6FC: main (crtools.c:789) Signed-off-by:
-
