- 27 May, 2014 9 commits
-
-
Pavel Emelyanov authored
Each task points to a single ID of cgroup-set it lives in. This is done so to save some space in the image, as tasks likely live in the same set of cgroups. Other than this we keep track of what cgroup set we dump the subtree from. If it happens, that root task lives in the same cgroup set as criu does, we don't allow for any other sub-cgroups and make restore (next patch) much simpler and faster. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
The exact structure of the image will be revealed in the next patch(es). What is important here, is that cgroup image is somewhat new. It will likely contain arrays of objects of different types, so I introduce the "header" object, that will link these arrays using pb repeated fields. This will help us to avoid many image files for different cgroup objects and will make the amount of write()-s required be 1. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Currently we build vDSO handling code for all archs provided in the source code having some "common" parts inside pie/vdso.c, pie/vdso-stub.c, vdso-stub.c and vdso.c. This were more or less well but in new linux kernels (starting from 3.16 presumably) the vDSO has been significantly reworked so every architecture must have own vDSO handling engine (just like the kernel does). So in this patch we move vDSO code to arch specific and because aarch64 actually doesn't implement proxification yet due to kernel restrictions -- we drops it out. When there will be kernel support we bring it back in proper arch/aarch64 implementation. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Guard vDSO code with CONFIG_VDSO, no need to even build it on archs which do not support vDSO handling. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
We will need it to figure out if architecture needs vDSO handling code to be built. Note currently only x86 is exporting vDSO simply because ARM support is not yet ready. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 26 May, 2014 6 commits
-
-
Filipe Brandenburger authored
Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Filipe Brandenburger authored
Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Filipe Brandenburger authored
This is required when linking statically. It is also consistent with the rules for other zdtm tests that link with -lrt. Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Filipe Brandenburger authored
Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Filipe Brandenburger authored
Without the added dependencies, "make criu" will fail when trying to build arch/x86/crtools.d because it can not find include/config.h, the extra dependencies force the "config" rule to be processed before the dependencies of "criu" are evaluated. Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Filipe Brandenburger authored
This is needed for lib/rpc.pb-c.{d,o} to be removed by "make clean". Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 23 May, 2014 2 commits
-
-
Andrey Vagin authored
vmsplice doesn't work for such VMA-s. This flags is set in a kernel function remap_pfn_range() (remap kernel memory to userspace), which is widely used by device drivers to provide direct access to a device memory. Reported-by:
J F <jgmb45@gmail.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
When there is a bind mount present on same mountpoint where mark is laying the device of both mountpoints is the same so we might end up getting wrong mountpoint. Instead we should used mount id which is unique among all mounpoints. Note it's a fast fix, I need to review fsnotify code more and make sure all corner cases are covered. https://bugzilla.openvz.org/show_bug.cgi?id=2974Reported-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 20 May, 2014 1 commit
-
-
Filipe Brandenburger authored
Add extra troubleshooting messages for errors and failures so that the output can help troubleshoot the issue. Make error handling more uniform by using -1 for errors (e.g. opening files, reading from pagemap, etc.) and 1 for failures (data mismatch, pages not COWed when expected to be, etc.) Tested: Ran this test with criu versions known to have problems with COW and with problems to read from pagemap due to the dumpable flag not being preserved. Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 14 May, 2014 3 commits
-
-
Andrey Vagin authored
The test proces opens master and slave points. The slave point becomes the control terminal for this process. Then the test process forks a second process and the first process closes the master point. So when a master point is closed in a second process, the first one will be killed by SIGHUP. Reported-by:
Victor Konyashkin <vkonyashkin@parallels.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
test/Makefile knows better how to execute tests. For example it allows to execute tests simultaneously Signed-off-by:
Andrey Vagin <avagin@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>
-
- 13 May, 2014 4 commits
-
-
Filipe Brandenburger authored
Preserve the dumpable flag, which affects whether a core dump will be generated, but also affects the ownership of the virtual files under /proc/$pid after restoring a process. Tested: Restored a process with a criu including this patch and looked at /proc/$pid to confirm that the virtual files were no longer all owned by root:root. zdtm tests pass except for cow01 which seems to be broken. (see https://bugzilla.openvz.org/show_bug.cgi?id=2967 for details.) This patch fixes https://bugzilla.openvz.org/show_bug.cgi?id=2968Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Change-Id: I8c386508448a84368a86666f2d7500b252a78bbf Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
We stop searching if vma->start is bigger than a required one. The coursor is set on the last examined vma. When we are searching a parent vma for the next vma, we start examine vma-s starting from coursor->next, so we don't examine the vma, which is pointed by cursor. This patch replaces list_for_each_entry_continue on list_for_each_entry_from. Reported-by:
Filipe Brandenburger <filbranden@google.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
A parent vma can be only one. Fixes: 57d25e7c ("mm: fix expression to determine which vma-s can be shared") Reported-by:
Filipe Brandenburger <filbranden@google.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
Look at this hunk from 7659c995: - paddr = decode_pointer(vma_premmaped_start(&p->vma)); + paddr = decode_pointer(vma->premmaped_addr); Obviously we want to use p->premmaped_addr instead of vma->premmaped_addr. Fixes: 7659c995 ("vm: don't overwrite vma->shmid for private mappings") Reported-by:
Filipe Brandenburger <filbranden@google.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 12 May, 2014 5 commits
-
-
Cyrill Gorcunov authored
Here we test a big number of small VMAs to survive c/r. The main idea is to use a big number of IOVs needed for page transferring. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
In a worst scenario we need one IOV for every page we're transferring from the parasite, thus don't divide by two here. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
* VDSO is never mapped with MAP_GROWSDOWN * The first page of growsdown vma may be a guard page, so any attempt to read it is suppressed by SIGBUS. Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Useful for debugging. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
We explicitly setns() every single task by hands when restoring mount namespaces, they can be created without the NEWNS flag. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Acked-by:
Andrey Vagin <avagin@parallels.com>
-
- 07 May, 2014 4 commits
-
-
Andrey Vagin authored
This test case creates two consecutive grows down vmas with a hole between them. Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
Currently we don't add a guard page to a second consecutive growsdonw vma, even if here is enough space for it. It's wrong. Look at the following test output: Execute zdtm/live/static/grow_map03 ./grow_map03 --pidfile=grow_map03.pid --outfile=grow_map03.out Dump 3888 Restore Test: zdtm/live/static/grow_map03, Result: FAIL ==================================== ERROR ==================================== Test: zdtm/live/static/grow_map03, Namespace: Dump log : /root/git/criu/test/dump/grow_map03/3888/1/dump.log --------------------------------- grep Error --------------------------------- ------------------------------------- END ------------------------------------- Restore log: /root/git/criu/test/dump/grow_map03/3888/1/restore.log --------------------------------- grep Error --------------------------------- pie: Error (pie/restorer.c:465): Unable to remap 0x7f0da2c99000 -> 0x7f46425fc000 pie: Error (pie/restorer.c:969): Restorer fail 3888 (00.035621) Error (cr-restore.c:1590): Restoring FAILED. ------------------------------------- END ------------------------------------- ================================= ERROR OVER ================================= strace: mremap(0x7fc3de5b6000, 0, 0, MREMAP_MAYMOVE|MREMAP_FIXED, 0x7f38dd4e0000) = -1 EINVAL (Invalid argument) Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
Our version of macroses are worng. Our macros: #define MINOR(dev) ((dev) & 0xff) Glibc function: return (__dev & 0xff) | ((unsigned int) (__dev >> 12) & ~0xff); Reported-by:
Amey Deshpande <ameyd@google.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
The page-pipe buffers may be reused once queued pages are dumped, but we happen to increase page_pipe::nr_pipes all the timer, regardless the fact where page buffer came from. In worst scenario this may lead to incorrect -EAGAIN returned from page_pipe_grow forcing calling code to create new pipes. This is not critical but should be fixed. In other words page_pipe::nr_pipes must track _really_ created pipes. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 25 Apr, 2014 4 commits
-
-
Pavel Emelyanov authored
We have made big step towards C/R of LXC containers -- made support for nested mount namespaces and addressed the re-attach issue. Also we have AArch64 support merged. Some work is still to be done, but it's good time to show what we have so far, thus -- the 1.3-rc1. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Christopher Covington authored
It's possible that a procfs mounted somewhere other than /proc is in use. Signed-off-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
https://bugzilla.openvz.org/show_bug.cgi?id=2949Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Andrey Vagin authored
v2: s/tun/mnt_id Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 24 Apr, 2014 1 commit
-
-
Andrey Vagin authored
Nested mount namespaces should be checked only if fdinfo contains mnt_id Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 23 Apr, 2014 1 commit
-
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-