- 14 Mar, 2017 18 commits
-
-
Dmitry Safonov authored
This will document that {get,set}_user_reg should be used only on initialized register set. Otherwise, after some code changes we may find ourself in situation when setting not inited user regs will set them for compatible register set: (is_native == false). Signed-off-by:Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Detect task's personality by the size of register set, returned by ptrace call with PTRACE_GETREGSET (more reliable). The same approach uses strace from 4.8 version: https://sourceforge.net/projects/strace/files/strace/4.8/Signed-off-by:
-
Dmitry Safonov authored
Introduced user_regs_struct32. Other changes mainly are reforming existing code to use the new register sets union. For protobuf images - reuse user_x86_regs_entry for both compatible and native tasks with enum in the beggining that describes register set type. That's better and simpler, than introducing a new 32-bit register set for compatible tasks. I tried to do this firstly with oneof keyword: https://github.com/0x7f454c46/criu/commit/499c93ae0e2b8ffb8c562f309bb046d77d6b07c0 But protobuf supports oneof keyword only from recent version 2.6.0, so I tried to rework it into enum + 2 register sets: https://github.com/0x7f454c46/criu/commit/aab4489bd4e0b1360b6e05614c2fce3ff2a52eb7 But that did not work either because restorer pie takes gpregs as thread_restore_args parameter and UserRegsEntry shouldn't contain pointers, but structure objects. This may be fixed by redefining UserRegsEntry not as typedef for UserX86RegsEntry, but containing needed objects, than treat it right for restorer - but that's more complicated that reusing user_x86_regs_entry. Signed-off-by:
-
Dmitry Safonov authored
Only parasite should be mode-depended, not restorer, as restorer will just switch to compatible mode with arch_prctl at the end and jump to 32-bit executable with sigreturn. So for parasite there are two targets: "native" and "compat", and one for restorer with the same name "restorer". It will result in parasite-native.o, parasite-compat.o and restorer.o objects. Pie build still may work with piegen or without it (gen-offset.sh). There are many FIXME in this patch, all them are in C code, that should be fixed to use compatible parsite when needed. Signed-off-by:
-
Dmitry Safonov authored
In code they yet use native parasite type, but in definition this parameter is not used (will be used at the next patch). Signed-off-by:
-
Dmitry Safonov authored
Signed-off-by:
-
Dmitry Safonov authored
Now compatible objects will be in $(obj)/compat/$(basename)-compat.o I can't use just $(obj)/compat/$(basename).o as basename for file will be the same as for native object, which wouldn't work by the reason of CFLAGS_$(F) in nmk-ccflags. So, I need different names for compatible/native objects. Because I don't want to make a mess in parent directories, I put this symlinks to compat/ dirs. This is how I came to that decision (even if I do not like it). Signed-off-by:
-
Dmitry Safonov authored
First pie library to use for compiling native pie. Signed-off-by:
-
Dmitry Safonov authored
Signed-off-by:
-
Dmitry Safonov authored
Impact: search sys-exec-tbl-32.c for compatible tasks. Rename task_in_compat_mode to arch_task_compatible and use it in find_syscall for 64-bit to check compatible task's syscall nr. It still will not execute syscall in 32-tasks, as we still do not have 32-bit pie (arch_can_dump_task will return false for these tasks). NOTE: be sure to `make mrproper` on criu directory before applying this patch, as before `criu/arch/x86/sys-exec-tbl.c` was autogenerated, it will make conflict if you try to apply this patch on dirty directory. Signed-off-by:
-
Dmitry Safonov authored
After uncommenting FIXME: It will add sc_exec_table_32 for compatible tasks to sys-exec-tbl.c Now it does: - add two different 32/64 syscall tables for cr-exec sys-exec-tbl-{64,32}. - add two different syscall headers syscall-{64,32}.h, that are included from more x86 generic syscall.h depending on -DCONFIG_X86_{32,64} option. - builds two different syscalls-{32,64}.built-in.o - for criu core files, that need SYS_memfd_create and other SYS_* __NR_* defines (currently kerndat.c and shmem.c), create simple syscall-codes.h that includes syscall-codes-64.h [Added after rebase on master] That way after apply, the compatible patch set will be simply able to bisect for regressions. Signed-off-by: -
Dmitry Safonov authored
Signed-off-by:
-
Cyrill Gorcunov authored
It's a hostprog so one target is enough, otherwise we're gitting double deps generation. Signed-off-by:
-
Cyrill Gorcunov authored
We don't need it actually. Signed-off-by:
-
Cyrill Gorcunov authored
The compel component is a replacement for several aspects of CRIU functionality: binary blobs generation for PIE parasite/restore code, and a library for parasite code injection and execution (to be implemented). In the commit we rather shuffle compel into own directory and use it for 1) Fetching cflags when compiling PIE blobs 2) Use its "piegen" functionality to generate blobs themselves. Signed-off-by:
-
Cyrill Gorcunov authored
Here we introduce actions: - "piegen" to generate blobs, which is used by criu already; - "cflags" and "ldflags" to print out options needed for compiler and linker when building compel compatible objects. We rather moved old "main" function body into piegen helper function and implement the rest of actions since they are one-liners. Note the usage uses new "compel" brand, but it's safe because we don't export anything yet. Signed-off-by: -
Cyrill Gorcunov authored
This will be needed to print out cflags and ldflags. Unused at moment. Signed-off-by:
-
Dmitry Safonov authored
Fixes the following error on travis-ci: CC arch/x86/syscalls/syscall32.o In file included from /usr/include/signal.h:28:0, from /home/travis/build/0x7f454c46/criu/criu/arch/x86/include/asm/types.h:5, from arch/x86/syscalls/syscall32.c:1: /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory # include <sys/cdefs.h> ^ Signed-off-by:
-
- 08 Mar, 2017 1 commit
-
-
Pavel Emelyanov authored
This is not a huge release. Some new stuff for Docker c/r and several bugs fixed. Signed-off-by:
-
- 07 Mar, 2017 1 commit
-
-
Pavel Emelyanov authored
The ipcns-shm images are buffered and contain raw dumps of memory contents. If the segment is huge, the bfd engine overflows and doesn't write data into image. This is not nice by itself, but huge images shouldn't use bfd to avoid double buffering. Also, in the future, this image should be fixed not to keep mem dumps in one image with object. https://github.com/xemul/criu/issues/287Signed-off-by:
-
- 06 Mar, 2017 20 commits
-
-
Kir Kolyshkin authored
A year ago this flag was removed, as parts of criu were build in sub-directories (i.e. by using make -C SUBDIR), and therefore paths printed by make were relevant to a SUBDIR rather than top source dir, which prevented tools like vim from jumping to a correct source file with with error (for more details, see commit XXXXXX "nmk: remove no-print-directory from MAKEFLAGS"). Now, as we have everything (except Documentation and test, which is rather minor) built from top source directory, we can finally add the flag back and enjoy cleaner output. Reviewed-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
-
Kir Kolyshkin authored
It was not working: > $ make DESTDIR=`pwd`/inst3 uninstall > UNINSTALL crit.1 > UNINSTALL criu.8 > UNINSTALL libcriu.so > UNINSTALL pkgconfig/criu.pc > UNINSTALL crit > /media/ts/kir/git/criu/scripts/nmk/scripts/build.mk:83: criu/arch/x86/Makefile: Not a directory > make[2]: *** No rule to make target 'criu/arch/x86/Makefile'. Stop. > Makefile:48: recipe for target 'criu/arch/x86/crtools.built-in.o' failed > make[1]: *** [criu/arch/x86/crtools.built-in.o] Error 2 > Makefile.install:49: recipe for target 'uninstall' failed > make: *** [uninstall] Error 2 This is a fix to commit 7a360484 ("build/make: return to make from top directory"). Reviewed-by:
-
Kir Kolyshkin authored
Our whole system of Makefiles are integrated from top to bottom, meaning: 1. The paths in sub-makefiles are relative to the top source dir. 2. Sub-makefiles are executed via make $(build)=<SUBDIR> <TARGET> For some reason, makefiles under lib/ are the exclusion. Let's fix it. Side effect: you can now build any individual target under lib/, for example, "make lib/c/libcriu.so" works. [v2: use the .FORCE, thanks to dsafonov@] Signed-off-by:
-
Kir Kolyshkin authored
Instead of removing everything by means of a few wildcards, let's properly generate the file names to be removed. [v2: fix a typo, thanks to dsafonov@] [v3: resend with a typo fixed for real, this time] Reviewed-by:
-
Andrei Vagin authored
If a pipe is inherited (external), it may be impossible to reopen it from a restored user namespace due to lack of permession, so in this case we have to reopen it via usernsd. https://github.com/opencontainers/runc/issues/1333Signed-off-by:
-
Andrei Vagin authored
================= Run zdtm/static/socket-tcp-nfconntrack in h ================== Start test Test is SUID ./socket-tcp-nfconntrack --pidfile=socket-tcp-nfconntrack.pid --outfile=socket-tcp-nfconntrack.out Another app is currently holding the xtables lock. Perhaps you want to use the -w option? Makefile:331: recipe for target 'socket-tcp-nfconntrack.pid' failed make: *** [socket-tcp-nfconntrack.pid] Error 1 Reported-by: Mr Travis Signed-off-by: -
Stanislav Kinsburskiy authored
"Check_fs_type" helper was repalce by "get_fs_type". This reference is a silly mistake. Signed-off-by:
Stanislav Kinsburskiy <skinsbursky@virtuozzo.com> Signed-off-by:
-
rbruno@gsd.inesc-id.pt authored
This is needed for the case when the target descriptor is image cache/proxy socket. Signed-off-by:
Rodrigo Bruno <rbruno@gsd.inesc-id.pt> Signed-off-by:
Katerina Koukiou <k.koukiou@gmail.com> Signed-off-by:
-
rbruno@gsd.inesc-id.pt authored
This is needed for the case when we get data from image-cache/proxy socket. Signed-off-by:
-
Pavel Emelyanov authored
After fds restore set merge we no longer need two lists. Don't BUG in eventpoll when the tfd is not on the list. This situation means that it's restored, so it's safe to report OK from this place. Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
Reviewed-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
-
Pavel Emelyanov authored
This is to avoid long item->pid->ns[0].virt for vpid(item). This is 1) for f in $(git grep -l 'ns\[0\]'); do sed -e 's/\([a-zA-Z0-9_]\+\)->pid->ns\[0\].virt/vpid(\1)/g' -i $f; done 2) adding of vpid() routine 3) some manual fixlets Reviewed-by: -
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
We should only get to the post-open stage for standalone sockets with peers. All the others return 0 from ->open which means "restore is over". This change avoids double calling or rst_file_params and restore_socket_opts for those ones. Signed-off-by:
-
Adrian Reber authored
Trying to use the FEATURE_CHECK RPC with criu_req->criu_opts set to NULL makes CRIU segfault. Technically there is no reason to have a valid criu_req->criu_opt during feature check. The only reason was to set the image directory for setproctitle(). This removes the segfault and the unnecessary requirement of setting criu_req->criu_opts. Another possible solution would have been to return an error if criu_req->criu_opts is NULL but so far it seems unnecessary to have criu_req->criu_opts during feature check. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
-
Kir Kolyshkin authored
This will help us catch bugs where the arguments are not in line with the format string. Signed-off-by:
-
