- 30 Dec, 2015 1 commit
-
-
Pavel Emelyanov authored
Otherwise non-parallel jenkins jobs miss the error logs in e-mails Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 29 Dec, 2015 14 commits
-
-
Andrew Vagin authored
Cc: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com> Fixes: c9448e1f ("arm: Fix wrong system call number") Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Vijaya Kumar K authored
arm64 requires stack pointer to be aligned to 16 bytes. Update all test cases that are using clone system call to have 16 byte aligned stack pointer. Signed-off-by:
Vijaya Kumar K <vijayak@caviumnetworks.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Vijaya Kumar K authored
arm64 requires stack to be aligned to 16 bytes. update RESTORE_ALIGN_STACK macro to always align to 16 bytes. Signed-off-by:
Vijaya Kumar K <vijayak@caviumnetworks.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Vijaya Kumar K authored
arm64 expects stack to be aligned to 16 bytes. If stack pointer is not aligned clone system call fails during restore. Signed-off-by:
Vijaya Kumar K <vijayak@caviumnetworks.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Vijaya Kumar K authored
System call number 78 corresponds to readlinkat. Where as 78 is mapped to readlink() in syscall.def for arm. With this patch, use sys_readlinkat instead of sys_readlink and update syscall.def to point syscall number 78 to readlinkat() instead of readlink() Signed-off-by:
Vijaya Kumar K <vijayak@caviumnetworks.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Dmitry Safonov authored
Impact: small cleanup Signed-off-by:
Dmitry Safonov <dsafonov@odin.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Dmitry Safonov authored
prepare_loginuid() called on kerndat_loginuid where it tests for loginuid restore feature. Let's omit error printing for feature test. Signed-off-by:
Dmitry Safonov <dsafonov@odin.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
Currently if criu segfaulted, the inventory image isn't removed and we can't detect that images are incomplete. Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
It's an example how it can be used Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
v2: set a control terminal Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
Now we can use the --inherit-fd option to mark external terminals on dump and to tell which file desdriptors should be used to restore these terminals. Here is an example how it works: $ setsid sleep 1000 $ ipython In [1]: import os In [2]: st = os.stat("/proc/self/fd/0") In [3]: print "tty[%x:%x]" % (st.st_rdev, st.st_dev) tty:[8800:d] $ps -C sleep PID TTY TIME CMD 4109 ? 00:00:00 sleep $ ./criu dump --external 'tty[8800:d]' -D imgs -v4 -t 4109 $ ./criu restore --inherit-fd 'fd[1]:tty[8800:d]' -D imgs -v4 v2: add missed break remove @non_file from tty_driver Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
This option is used to mark external resources on dump. Currently it's going to be used to handle external tty-s, but in a future it can be used to any type of resources. We can have a few ways to restore external resources and we will have a separate options to say how to restore each type. For example, we can use --inherit-fd to restore external file descriptors. Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
We can't use only a terminal device, because we can not distinguish two pty-s from different mounts in this case. $ mount -t devpts -o newinstance xxx pts1 $ mount -t devpts -o newinstance xxx pts2 $ stat pts1/0 Device: 27h/39d Inode: 3 Links: 1 Device type: 88,0 $ stat pts2/0 Device: 28h/40d Inode: 3 Links: 1 Device type: 88,0 Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 28 Dec, 2015 9 commits
-
-
Pavel Emelyanov authored
Right now if we bind-mount / of some FS into container and want this to be 'external' mount, criu would refuse to dump this mountpoint. Tune the check in validate_mounts() to always accept any external mps regardless of whether they are fsroot or not. https://github.com/xemul/criu/issues/93Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Tested-by:
Dengguangxing <dengguangxing@huawei.com>
-
Andrew Vagin authored
Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
timer_t is (void *) in glibc, but timer_t is (int) in kernel. When we call system calls, we need to use timer_t from kernl. https://github.com/xemul/criu/issues/98Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Use explicit type to placate the compiler. | proc_parse.c: In function 'vma_get_mapfile': | proc_parse.c:282:6: error: format '%lx' expects argument of type 'long unsigned | int', but argument 5 has type 'uint64_t' [-Werror=format=] | pr_err("Strange file mapped at %lx [%s]:%d.%d.%ld\n", | ^ | proc_parse.c:335:5: error: format '%lx' expects argument of type 'long unsigned | int', but argument 5 has type 'uint64_t' [-Werror=format=] | pr_err("Failed to resolve mapping %lx filename\n", | ^ | cc1: all warnings being treated as errors Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrew Vagin authored
We were not going to change it on dump Cc: Dmitry Safonov <dsafonov@odin.com> Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Dmitry Safonov authored
Loginuid tests should run only when kdat.has_loginuid set. This is for > 3.13 kernels with CONFIG_AUDITSYSCALL enabled. Signed-off-by:
Dmitry Safonov <dsafonov@odin.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Dmitry Safonov authored
Dump/Restore loginuid value only when kdat.has_loginuid set. Signed-off-by:
Dmitry Safonov <dsafonov@odin.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Dmitry Safonov authored
This value will differ on C/R: - on checkpoint it means that it's possible to dump logiuid values; - on restore it means that it's possible to unset loginuid and write saved value to unsetted loginuid. Signed-off-by:
Dmitry Safonov <dsafonov@odin.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 25 Dec, 2015 2 commits
-
-
Cyrill Gorcunov authored
rst_mem_alloc rules might move previously allocated blocks which means we can't reuse previously allocated pointer if new block is created. Thus remember pointers positions where needed and adjust them accordingly. https://github.com/xemul/criu/issues/97Reported-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
On restore we try to put data back into recv queue with quite big chunks. However the kernel doesn't try hard to split the data into packets in repair mode for this queue and just allocates the linear skb of the given size. If the size is moderately big, the allocation is subject to fail, slab doesn't reliably allocates memory over 4k. So, when failing with big chunk on recv queue -- shrink the chunk and try again. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Acked-by:
Andrew Vagin <avagin@virtuozzo.com>
-
- 24 Dec, 2015 14 commits
-
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Some tests require criu to be root, e.g. tcp tests of unlink-mmaps ones, so mark those in desc files as such. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
This is fixlet to patch #2. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
There are several restrictions: 1. Onlu dump is checked (--norst) for now 2. Only host flavor as tests has to start themselves in non-root mode 3. Only non-suid tests 4. TCP doesn't work too, should be manually excluded :\ Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
Currently parasite is loaded using the map_files dir, which is guarged with CAP_SYS_ADMIN by default (which is dropped in 4.2 series). So lets do a deal -- try to use memfd interface first (which has been introduced in 4.0 kernel series) and if we fail then switch to old map_files interface. With time all users are switched to new kernels so memfd gonna be primary interface. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Kernel doesn't allow to mess with map_files dir in proc. So, when doing dump from user process, we should try to get file path using path from smaps file. To be 100% sure the path is correct we also get device and ino numbers and check them agains the stat()-ed path ones. With this scheme we miss - mapped packet sockets, but users don't use them - AIOs, but this can be detected via device, inode and name - several nested mntns's, but users don't use them - mapped and unlinked files, but this can be fixed by reading file via task's memory (slow, but still) gorcunov@: - For special mappings such as heap, vsyscall, vdso and such the kernel provides names rounded by brackets so exit from vma_get_mapfile if we meet one and allow the caller to handle it. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
If criu is running in unprivileged mode and we can't access dumpee's pagemap file -- simply switch to greedy mode where all pages are gonna be dumped regardless of their presence in memory. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
We use page frame number to detect vDSO which has been remapped in-place from runtime vDSO during restore. In such case if the kernel is younger than 3.16 the "[vdso]" mark won't be reported in procfs output. Still to address recently reported CVEs and be able to run CRIU in unprivileged mode we need to handle vDSO without pagemap access and here is the deal -- when we find VMA which "looks like" vDSO we try to scan it for vDSO symbols and if it matches we restore its status without PFN access. Here is some details on @pagemap access in-kernel history: - @pagemap introduced in commit 85863e475e59 where anyone which can attach to a task via ptrace is allowed to read data from @pagemap (Feb 4 2008, v2.6.25-rc1) - in commit 006ebb40d3d65 ptrace attach rule has been changed into ptrace read permission (May 19 2008, v2.6.27-rc1) - in commit ab676b7d6fbf4 opening of @pagemap become guarded with CAP_SYS_ADMIN because of leak of physical addresses into userspace (Mar 9 2015, v4.0-rc5) - in commit 1c90308e7a77a opening of @pagemap become available for regular users again (with ptrace read permission) but physical addresses of pages are hidden from non-privileged userd (Sep 8 2015, v4.3-rc1) Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
In particular, we won't be able to do memory tracking and zero page detection. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Kernel doesn't allow to read /proc/pid/map_files. This file is used to get pseudo device for anon shmem mappings, but this info can be get by scanning /proc/self/maps file. This works slower, but still. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
When run from regular user criu will get EACCES/EPERM from opening proc, but in some situations criu will now how to deal with it. So this patch makes it possible not to print error message in logs for such cases. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
We will need an extra space for memfd based syscall (without poking the stack since it's not that safe without additional tests). So add @pad argument which will be used to find proper memory for seized syscall execution. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Right now we only get first 31 symbols of it, but in the next patches full path would be required. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
-