- 15 Aug, 2017 6 commits
-
-
Andrei Vagin authored
Otherwise someone can include kerndat.h before config.h and get another kerndat structure. For example, proc_parse doesn't include config.h and Cyrill met this problem. Cc: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
-
Pavel Emelyanov authored
There's potential NULL-derefernece in dump_netns_con() -- two xmalloc results are not checked. However, since there's a huge set of these xmallocs, I propose to relax the whole thing with one big xmalloc and xptr_pull() helper. Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
-
Kirill Tkhai authored
It's unused and it's rewritten in shmem_wait_and_open(), and it just confuses a reader. So, kill it. Signed-off-by:Kirill Tkhai <ktkhai@virtuozzo.com>
-
Alice Frosi authored
For dumping threads we execute parasite code before we collect the floating point registers with get_task_regs(). The following describes the code path were this is done: dump_task_threads() for (i = 0; i < item->nr_threads; i++) dump_task_thread() parasite_dump_thread_seized() compel_prepare_thread() prepare_thread() ### Get general purpose registers ### ptrace_get_regs(ctx->regs) ### parasite code is executed in thread ### compel_run_in_thread(tctl, PARASITE_CMD_DUMP_THREAD) compel_get_thread_regs() ### Get FP and VX registers ### get_task_regs() Since on s390 gcc uses floating point registers to cache general purpose without the -msoft-float option the floating point registers would have been clobbered after compel_run_in_thread(). With this patch we first save all thread registers with task_get_regs() and then call the parasite code. We introduce a new function arch_set_thread_regs() that restores the saved registers for all threads. This is necessary for criu dump --leave-running, --check-only, and error handling. Pre-dump does not require to save the registers for the threads because because only the main thread (task) is used for parsite code execution. The above changes allow us to use all register sets in the parasite code - therefore we can remove -msoft-float on s390. Reviewed-by:Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by:
Alice Frosi <alice@linux.vnet.ibm.com> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Michael Holzheu authored
This test can be used to verify FP and VX registers on s390: - Verify that "criu restore" sets the correct register sets from "criu dump": $ zdtmp.py run -t zdtm/static/s390x_regs_check - Verify that dumpee continues running with correct registers after parasite injection: $ zdtm.py run --norst -t zdtm/static/s390x_regs_check $ zdtm.py run --norst --pre 2 -t zdtm/static/s390x_regs_check $ zdtm.py run --check-only -t zdtm/static/s390x_regs_check Reviewed-by:
-
Michael Holzheu authored
We have to include Makefile.inc earlier in order to use SRCARCH. Signed-off-by:
-
- 09 Aug, 2017 34 commits
-
-
Adrian Reber authored
The upcoming glibc release renamed 'struct ucontext' to 'struct ucontext_t': https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=251287734e89a52da3db682a8241eb6bccc050c9;hp=c86ed71d633c22d6f638576f7660c52a5f783d66 Instead of using 'struct ucontext' this patch changes it to the typedef ucontext_t which already exists in older and new versions of glibc. Signed-off-by:
Adrian Reber <areber@redhat.com> Reviewed-by:
-
Adrian Reber authored
The upcoming glibc release renamed 'struct ucontext' to 'struct ucontext_t': https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=251287734e89a52da3db682a8241eb6bccc050c9;hp=c86ed71d633c22d6f638576f7660c52a5f783d66 Instead of using 'struct ucontext' this patch changes it to the typedef ucontext_t which already exists in older and new versions of glibc. Signed-off-by:
-
Adrian Reber authored
The upcoming glibc release renamed 'struct ucontext' to 'struct ucontext_t': https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=251287734e89a52da3db682a8241eb6bccc050c9;hp=c86ed71d633c22d6f638576f7660c52a5f783d66 Instead of using 'struct ucontext' this patch changes it to the typedef ucontext_t which already exists in older and new versions of glibc. Signed-off-by:
-
Adrian Reber authored
Signed-off-by:
-
Gianfranco Costamagna authored
This fixes the ppc64el build failure CC criu/arch/ppc64/sigframe.o In file included from criu/arch/ppc64/sigframe.c:5:0: criu/arch/ppc64/include/asm/types.h:32:0: error: "AT_VECTOR_SIZE_ARCH" redefined [-Werror] #define AT_VECTOR_SIZE_ARCH 6 Signed-off-by: -
Michael Holzheu authored
The entries in /proc/<pid>/maps look like the following: 3fffffdf000-40000000000 rw-p 00000000 00:00 0 The upper address is the first address that is *not* included in the address range. Our function max_mapped_addr() should return the last valid address for a process, but currently returns the first invalid address. This can lead to the following error message on kernel that have kernel commit ee71d16d22bb: Error (criu/proc_parse.c:694): Can't dump high memory region 1ffffffffff000-20000000000000 of task 24 because kernel commit ee71d16d22bb is missing Fix this and make max_mapped_addr() the last valid address (first invalid address - 1). Reported-by:
-
Michael Holzheu authored
We currently define "CFLAGS += -msoft-float -fno-optimize-sibling-calls" in Makefile.compel. Makefile.compel is included into the toplevel Makefile and so changes CFLAGS which are exported to all criu and zdtm Makefiles. We must not use -msoft-float outside the compel files. E.g. otherwise for zdtm we get the following build error: uptime_grow.o: In function `main': /tmp/2/criu/test/zdtm/static/uptime_grow.c:36: undefined reference to `__floatdidf' /tmp/2/criu/test/zdtm/static/uptime_grow.c:36: undefined reference to `__muldf3' /tmp/2/criu/test/zdtm/static/uptime_grow.c:36: undefined reference to `__floatdidf' /tmp/2/criu/test/zdtm/static/uptime_grow.c:36: undefined reference to `__adddf3 Fix this and move the CFLAGS definition to the compel Makefiles. We do this by defining a new flag CFLAGS_PIE that is only used for pie code. Reported-by:
-
Michael Holzheu authored
We have to use "debian.jessie" instead of "ubuntu.xenial" because qemu-s390x-static can only run z900 instructions and Ubuntu is built with a more recent architecture level set. We first enable only gcc because there are still some issues with clang. Signed-off-by:
-
Michael Holzheu authored
Debian is compiled for z900 - therefore we can't use the "laa" instruction. Fix this and replace "laa" by the older "cs" (compare and swap) loop. Signed-off-by:
-
Michael Holzheu authored
The flogr instruction not supported by debian jessie (z900). So replace it by the gcc built-in. Signed-off-by:
-
Michael Holzheu authored
Use the "-fno-optimize-sibling-calls" gcc option to prevent GOT relocations caused by gcc versions without the commit "S/390: Fix 64 bit sibcall": * https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=233169 Otherwise we get compile errors like: GEN criu/pie/parasite-blob.h Error (compel/src/lib/handle-elf-host.c:572): Unsupported relocation of type 26 Those can be caused by the following relocation types: * R_390_GOTENT (e.g. RHEL7 based systems) * R_390_GOTPCDBL (e.g. Debian Jessie) * R_390_GOT12 (e.g. Debian Jessie) Signed-off-by:
-
Michael Holzheu authored
For kernels that don't have commit ee71d16d22 ("s390/mm: make TASK_SIZE independent from the number of page table levels") criu sets TASK_SIZE to 4 TB on s390 (see compel_task_size()). When dumping tasks >= 4 TB on such systems, we would silently loose memory >= 4TB. So add a check and refuse to dump the task in that case. When restoring tasks >= 4 TB on such systems, the remap() call for moving the vmas at the end of the restor process would fail and a very unclear error message is printed. So add a check and write a more speaking error message in that case. Reviewed-by: -
Michael Holzheu authored
On s390 we have special console drivers with minors 64 and 65. Add support for them in criu code and in zdtm testsuite. Reviewed-by:
-
Michael Holzheu authored
If the kernel contains patch ee71d16d22 ("s390/mm: make TASK_SIZE independent from the number of page table levels") we are able to checkpoint tasks > 4TB. Add a testcase to verify this. Signed-off-by: -
Michael Holzheu authored
Reviewed-by:
-
Michael Holzheu authored
Reviewed-by:
-
Michael Holzheu authored
Add s390 parts to common code files. Patch history ------------- v2->v3: * Add: Fix big endian byte order checks Reviewed-by:
-
Michael Holzheu authored
Reviewed-by:
-
Michael Holzheu authored
Reviewed-by:
-
Michael Holzheu authored
Add s390 parts to common code files. Patch history ------------- v2->v3: * Add: s390: Consolidate -msoft-float into Makefile.compel Reviewed-by:
-
Michael Holzheu authored
This patch only adds the support but does not enable it for building. Reviewed-by:
-
Pavel Emelyanov authored
This completes merging files images into one. Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
Same here -- now when we collect info and driver at the same place late enough we can verify info once, then attach to files. Signed-off-by:
-
Pavel Emelyanov authored
Since we need tty driver for info, we may lookup the guy when collecting info, not when attaching it to a file. Signed-off-by:
-
Pavel Emelyanov authored
There are two object for TTY files -- the file itself and tty_info. The latter is effectively an inode image. Right now we collect infos before files, so that latter can find former and attach to it. In order to move tty files on generic file entry we need to collect files very early, much earlier, that infos. So here's the patch that changes the order of tty file vs info collection. The general idea is -- when collecting files put them in a list and when an info arrives it walks that list and attaches ttys to self. Next patches will also add some optimization available with that scheme. Signed-off-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
