- 27 Jun, 2014 11 commits
-
-
Pavel Emelyanov authored
v2: * introduce the run_test helper * fix overall result detection Signed-off-by:Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
It's derived from test.c, but is more self-contained and explicitly checks for both C and R results. Signed-off-by: -
Pavel Emelyanov authored
Which is at the same time the demonstration of how to do the trick. v2: * remove stupid sleep 1 synchronization * run internal version of child, not the external script Signed-off-by:
Andrew Vagin <avagin@parallels.com>
-
Pavel Emelyanov authored
It fully uses the swrk action of criu. The problems, that caller may have is that the restored tasks die _before_ libcriu's call returns. v2: * rename _sub to _child * unblock sigchild before execl-ing criu Signed-off-by: -
Pavel Emelyanov authored
This is to prepare a send-and-recv routine that works on existing socket. Signed-off-by: -
Pavel Emelyanov authored
To help restoring tasks from images as kids to the caller, we can do the trick. 1. Caller sets himself as child reaper with PR_SET_CHILD_SUBREAPER prctl 2. Caller makes sure criu binary is suid-ed and owned by root 3. Caller forks and calls execv() on criu asking it to restore 4. Criu finishes restore and exits. All its kids get reparented to the criu's parent, i.e. -- to the library caller. 5. Caller stops being subreaper In order to make the execv() and arguments passing simpler I propose to execv() the service worker function, that accepts options via socket. This is good for two reasons. 1. We don't have to construct CLI options in libcriu 2. We reuse other service's facilities, such as security checks, ability to dump, pre-dump and other stuff Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
These are just copy the value on RPC message and do nothing more. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by:
-
- 26 Jun, 2014 2 commits
-
-
Filipe Brandenburger authored
Building criu with "make criu" on a clean tree was not working, failing on: make[1]: *** No rule to make target `arch/x86/vdso-pie.o'. Stop. make: *** [arch/x86/vdso-pie.o] Error 2 git bisect traced the regression to commit c473461d (vdso: Make it arch specific) which apparently dropped the rule to build $(ARCH_DIR)/vdso-pie.o using the pie rule. Restore the dependency for "make criu" to work again from a clean tree. Tested: $ git clean -fdx $ make criu Fixes: c473461dSigned-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Chris J Arges authored
If we build with something like: make LDFLAGS="-Wl,-Bsymbolic-functions" We'll get an error because the LDFLAGS are being passed to LD when they should be pased to CC. Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Acked-by:
-
- 25 Jun, 2014 11 commits
-
-
Filipe Brandenburger authored
Robust lists may be disabled, for example if the "futex_cmpxchg_enabled" variable in the kernel is unset. Detect that case by checking that both "get_robust_list" and "set_robust_list" syscalls return ENOSYS and do not make criu dump fail in that case, but simply assume an empty list, which is consistent with the syscalls not being available. Tested: Successfully ran the zdtm test suite on a kernel where the "get_robust_list" and "set_robust_list" syscalls are disabled. Signed-off-by:
-
Saied Kazemi authored
Skip the string "name=" when recreating cgroups directories in cgyard. For example, systemd's entries in cgroup.img are: name: "name=systemd" path: "/user/1000.user/4.session" When creating systemd subdir, named= should not be part of the name. Signed-off-by:
Saied Kazemi <saied@google.com> Signed-off-by:
-
Andrey Vagin authored
The newinstance options isn't shown in mountinfo. Currently it is detected in devpts_dump. It is added only for root mounts and it isn't added for bind-mounts. So mounts_equal(a, b, true) returns false for such mounts and criu doesn't understand that they should be bind-mounted. Reported-by:
Tycho Andersen <tycho.andersen@canonical.com> Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Acked-by:
Serge E. Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Andrey Vagin authored
Signed-off-by:
-
Cyrill Gorcunov authored
On PI we've noticed that CLOCK_BOOTTIME might not be defined in system headers, so ship own one. Signed-off-by:
-
Cyrill Gorcunov authored
Otherwise we might have a clash | Execute zdtm/live/static/vdso01ns/static/pipe00 Reported-by:
Andrew Vagin <avagin@gmail.com> Signed-off-by:
-
Andrew Vagin authored
Signed-off-by:
-
Tycho Andersen authored
Signed-off-by:
-
Andrey Vagin authored
Signed-off-by:
-
Cyrill Gorcunov authored
To be able to run specific tests depending on architecture we're executing on. Signed-off-by:
-
Cyrill Gorcunov authored
It parses vDSO in memory (just like CRIU does) and then use direct calls to vDSO entries instead of .plt/.got bundle. The reason for that -- I must be sure we're able to proceed calls without relying on libc anyhow. Note the test is x86-64 specific so I don't turn in on in test suite by default. Signed-off-by:
-
- 24 Jun, 2014 16 commits
-
-
Pavel Emelyanov authored
When opening a reg file on restore -- check that the file size we opened matches the on we saw on dump. This is not bullet-proof protection, but is helpful to protect against FS updates between dump/restore. Signed-off-by: -
Cyrill Gorcunov authored
To test CLOCK_BOOTTIME feature recently implemented in OpenVZ kernel. Vanilla kernel and CRIU passes it. Signed-off-by:
-
Pavel Emelyanov authored
Otherwise cgroups sub-mounts may propagate to another namespaces and the directory would become unremovable. Signed-off-by: -
Andrew Vagin authored
make -C test other Signed-off-by:
-
Andrey Vagin authored
run.sh: line 17: xip: command not found Signed-off-by:
-
Cyrill Gorcunov authored
Otherwise we're meeting somehow corrupted mark and must abort dumping. Reported-by:
-
Cyrill Gorcunov authored
New kernel 3.16 will have old vDSO zone splitted into the two vmas: one for vdso code itself and second that named vvar for data been referenced from vdso code. Because I can't do 'dump' and 'restore' parts of the code separately (otherwise test would fail) the commit is pretty big one and hard to read so here is detailed explanation what's going on. 1) When start dumping we detect vvar zone by reading /proc/pid/smap and looking up for "[vvar]" token. Note the vvar zone is mapped by a kernel with PF/IO flags so we should not fail here. Also it's assumed that at least for now kernel won't be changed much and [vvar] zone always follows the [vdso] zone, otherwise criu will print error. 2) In previous commits we disabled dumping vvar area contents so the restorer code never try to read vvar data but still we need to map vvar zone thus vma entry remains in image. 3) As with previous vdso format we might have 2 cases a) Dump and restore is happening on same kernel b) Dump and restore are done on different kernels To detect which case we have we parse vdso data from image and find symbols offsets then compare their values with runtime symbols provided us by a kernel. If they match and (!!!) the size of vvar zone is the same -- we simply remap both zones from runtime kernel into the positions dumpee had at checkpoint time. This is that named "inplace" remap (a). If this happens the vdso_proxify() routine drops VMA_AREA_REGULAR from vvar area provided by a caller code and restorer won't try to handle this vma. It looks somehow strange and probably should be reworked but for now I left it as is to minimize the patch. In case of (b) we need to generate a proxy. We do that in same way as we were before just include vvar zone into proxy and save vvar proxy address inside vdso mark injected into vdso area. Thus on subsequent checkpoint we can detect proxy vvar zone and rip it off the list of vmas to handle. Signed-off-by: -
Cyrill Gorcunov authored
Because of new vvar area we need to carry the address of vvar proxy inside the mark. Thus add members needed and update routines. Signed-off-by:
-
Cyrill Gorcunov authored
This is for debug purpose mostly. Signed-off-by:
-
Cyrill Gorcunov authored
vvar zone is mapped by a kernel and must not ever been dumped into image, the data present there is valid on running kernel only. Signed-off-by:
-
Cyrill Gorcunov authored
Will need it to handle vvar zones in a special way. Because VMA_UNSUPP never goes into the image file lets reuse bit 12 for VVAR. Signed-off-by:
-
Filipe Brandenburger authored
The /dev directory is also created by zdtm when running ns/ enabled tests. Add it to the list, together with entries such as /bin and /lib. Signed-off-by:
-
Filipe Brandenburger authored
This adds new tests "cgroup00" and "clean_mntns" to the .gitignore file. Signed-off-by:
-
Filipe Brandenburger authored
This confirms that the fix to handle dumpable flag set to 2 still works after restore. To force dumpable flag set to 0 or 2 (whatever the fs.suid_dumpable is set to), chmod the test binary to 0111 (executable, but not readable) and execv() it while running as non-root. The kernel will unset the dumpable flag to prevent a core dump or ptrace to giving the user access to the pages of the binary (which are supposedly not readable by that user.) Tested: - # test/zdtm.sh static/dumpable02 Test: zdtm/live/static/dumpable02, Result: PASS - # test/zdtm.sh ns/static/dumpable02 Test: zdtm/live/static/dumpable02, Result: PASS - Used -DDEBUG to confirm the value of the dumpable flag was 0 or 2 to match the fs.suid_dumpable sysctl in the tests (both in and out of namespaces.) - Confirmed that the test fails if the commit that fixes handling of dumpable flag with value 2 is reverted and the fs.suid_dumpable sysctl is set to 2. Signed-off-by:
-
Filipe Brandenburger authored
Commit d5bb7e97 started to preserve the dumpable flag across migration by using prctl to get the value on dump and set it back on restore. On some situations, the dumpable flag can be set to 2. This happens when it is not reset (with prctl) after using setuid() or after using execv() on a binary that has executable but not read permissions, when the fs.suid_dumpable sysctl is also set to 2. However, it is not possible to set it to 2 using prctl, which would make criu restore fail. Fix this by checking for the value before passing it to prctl. In case the value of the dumpable flag was 2 at the source, check whether it is already 2 at the destination, which is likely to happen if the fs.suid_dumpable sysctl is also set to 2 where restore is running. In that case, preserve the value, otherwise reset it to 0 which is the most secure fallback. Fixes: d5bb7e97 Tested: - Using dumpable02 zdtm test after setting fs.suid_dumpable to 2. # sysctl -w fs.suid_dumpable=2 # test/zdtm.sh ns/static/dumpable02 4: DEBUG: before dump: dumpable=2 4: DEBUG: after restore: dumpable=2 4: PASS Test: zdtm/live/static/dumpable02, Result: PASS Signed-off-by:
-
Filipe Brandenburger authored
This reverts commit 8870aa1e. Signed-off-by:
-
