- 14 Feb, 2014 6 commits
-
-
Pavel Emelyanov authored
We want to write into empty image files, so we unlink them before dumping into. Let's O_TRUNC it instead. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Acked-by:
Andrew Vagin <avagin@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
-
Pavel Emelyanov authored
We spend a lot of time reading the /proc/$pid/smaps file. The time is spent in two places: 1 kernel puts too many info into it 2 fgets pulls info in 1024-bytes chunks, info about one vma is typically bigger (up to 3k bytes) thus we call read() ~3 times per one vma, which increases the amount of time spent in kernel to re-fill this info Setting the internal buffer to PAGE_SIZE size reduces the amount of read()-s on ~60% during basic container dump. Setting bigger buffer doesn't work, as kernel's seq file engine feeds at most one page of data per read syscall regardless of the buffer size. Signed-off-by:
-
Andrey Vagin authored
This function splices data from a process to criu, so dump_pages describes the real meaning. Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Andrey Vagin authored
Before this patch, criu splices all data in pipes and then saves these data in a image file. Here is a problem, becase creating pipes with big buffers fails too often, because a kernel tries to allocate a big linear chunks of memory. Now memory are dumped for a few iterations, where the size of pipe buffers is restricted. Signed-off-by:
-
Andrey Vagin authored
PIPE_MAX_SIZE is calculated according with the kernel code. PPB_IOV_BATCH has been taken from my mind. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
- 13 Feb, 2014 1 commit
-
-
Pavel Emelyanov authored
Acked-by:
-
- 11 Feb, 2014 4 commits
-
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
This is the first time restorer gets info back from CRIU service. At that time it makes perfect sense to report what PID we're working with. Signed-off-by: -
Christopher Covington authored
This allows building with busybox sed, for example. Signed-off-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
-
Cyrill Gorcunov authored
In commit 459828b6 I suddenly broke backward compatibility of auxv vector on 32bit machines. Bring it back. Reported-by:
-
- 10 Feb, 2014 17 commits
-
-
Pavel Emelyanov authored
We call tar, ip, iptables, etc. when restoring container. The problem is that these stuff is called from inside new mount namespace after pivot_root(). But the execvp uses PATH variable inherited from the host system, which may not reflect real binaries layout. Add "/bin" to path as temporary workaround. Signed-off-by: -
Pavel Emelyanov authored
When live-migrating a container on NFS the link-remap cannot create original file on target machine, since the file name is still visible -- source CT is alive. The proper fix would be to move file aside, then create link, then move original file back, but since NFS changes file name anyway, we just do the same -- generate another name for link. Signed-off-by: -
Andrey Vagin authored
Before this patch, criu splices all data in pipes and then saves these data in a image file. Here is a problem, becase creating pipes with big buffers fails too often, because a kernel tries to allocate a big linear chunks of memory. Now memory are dumped for a few iterations, where the size of pipe buffers is restricted. TODO: need to rework pre-dump, because currently dumping data from pipes are postponed. We are going to use sys_process_vm_readv for this. Signed-off-by: -
Andrey Vagin authored
It's preparation to dump memory by chunks. Signed-off-by:
-
Andrey Vagin authored
The problem is that vmsplice() to a big pipe fails very often. The kernel allocates a linear chunk of memory for pipe buffer descriptos, but a big allocation in kernel can fail. So we need to restrict maximal capacity of pipes. But the number of pipes is restricted too, so we need to split dumping memory on chunks. In this patch we calculates the pipe size for which vmsplice() will not fail. v2: s/batch/chunk and a few other small fixes v3: Remove callbacks from page_pipes and reuse pipes Signed-off-by:
-
Christopher Covington authored
The following issue is possibly caused by using busybox make. protobuf/packet-sock.pb-c.c: In function 'packet_sock_entry__init': protobuf/packet-sock.pb-c.c:98:3: error: this decimal constant is unsigned only in ISO C90 [-Werror] Use a belt-and-suspenders approach to ensure it doesn't happen. Signed-off-by: -
Christopher Covington authored
The current -march settings will cause an error if the user a conflicting flags such as -mcpu=cortex-a15. Use USERCFLAGS instead of CFLAGS so that a default is provided but can be overridden. Change-Id: I8ffecd6bfd7ad5794486a5d14d27bce3170898d3 Acked-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
-
Christopher Covington authored
Ideally, a user could set CFLAGS on the command line to contain compilation options and include and library paths (or maybe set those last two with CPPFLAGS and LDFLAGS). Unfortunately, setting CFLAGS on the command line currently short-circuits essential logic in the makefile and breaks the build. After a first failed attempt it appears that a monolithic overhaul or "flag day" to fix this is a substantial undertaking, so for now just provide a workaround in the form of a USERCFLAGS variable. Signed-off-by: -
Christopher Covington authored
Perhaps left over from when a single types.h was being used for multiple architectures, remove the ARM definition of AT_VECTOR_SIZE from the x86 types.h header. Also remove the CONFIG_ARM definition since it unused. Acked-by:
-
Christopher Covington authored
The current mechanism for determining ARM architecture version breaks down when cross-compiling. Default to ARMv7 if the user specifies ARCH=arm. Users wishing to cross-compile for ARMv6 platforms such as the Raspberry Pi should use ARCH=armv6 as previously required. Acked-by:
-
Christopher Covington authored
Without this a user may encounter the following error. arch/arm/include/asm/atomic.h:38:2: error: implicit declaration of function ‘smp_mb’ With the #error pragma a user is a least pointed to the specific section in the file that's causing the problem arch/arm/include/asm/atomic.h:21:2: error: #error ARM architecture version (CONFIG_ARMV*) not set or unsupported. Acked-by:
-
Christopher Covington authored
ARCH is a user-facing variable and setting it on the command line clobbers any manipulation attempted in the makefile. Following the example of the Linux kernel makefiles, use a SRCARCH variable instead for the internal, potentially fixed-up, architecture name. This fixes the following error. make ARCH=x86_64 Makefile:69: *** "The architecture x86_64 isn't supported". Stop. Signed-off-by: -
Christopher Covington authored
The top-level makefile defines an ARCH_DIR variable. Always use it rather than referencing ARCH directly, since ARCH may be set by the user on the command line and that raw input may not be what needs to be used internally. Signed-off-by: -
Christopher Covington authored
A user may have necessary linker directories specified in CFLAGS. Make sure to include them. Change-Id: I76c2a7bd6e34cc282bfcd5f83cc69ae7fa2c8cc2 Signed-off-by: -
Christopher Covington authored
The makefile includes need to be moved for everything to be defined properly when the configure tests run. The Ubuntu 12.04 x86_64 GCC and Linaro's 13.08 and newer AArch64 GCC's have the if_packet.h kernel header, but as of 13.12, the Linaro AArch32 GCC does not. Change-Id: I363c43fdb81b028f99aac77e15bff9462c87af4b Signed-off-by: -
Adrian Reber authored
The links to the versioned libcriu.so.* included $(DESTDIR) and $(LIBDIR) which will generate wrong links if building criu packages. Now the links points to the correct file without any path. For some reason criu.8 was installed with executable permission. Use 'install' with '-m 644' to make sure this does not happen. Signed-off-by:
Adrian Reber <adrian@lisas.de> Signed-off-by:
-
Cyrill Gorcunov authored
No need to read it in cycle. Repored-by:
-
- 07 Feb, 2014 12 commits
-
-
Cyrill Gorcunov authored
Repeated custom entries are presented as an array of pointers in the memory, so once we fetch the first entry we are to continue iterating pointers instead. Before | vmas: { | start: 0x00000000400000 | end: 0x00000000406000 | pgoff: 0000000000000000 | shmid: 0x0000000000000b | prot: 0x5 | flags: 0x2 | status: 0x41 | fd: 0xffffffffffffffff | } | :{ | start: 0x00000000462d00 | end: 0000000000000000 | pgoff: 0000000000000000 | shmid: 0x00000000605000 | prot: 0x606000 | flags: 0 | status: 0x5000 | fd: 0x0000000000000b | madv: 0x00000000000041 | } After | vmas: { | start: 0x00000000400000 | end: 0x00000000406000 | pgoff: 0000000000000000 | shmid: 0x0000000000000b | prot: 0x5 | flags: 0x2 | status: 0x41 | fd: 0xffffffffffffffff | } | :{ | start: 0x00000000605000 | end: 0x00000000606000 | pgoff: 0x00000000005000 | shmid: 0x0000000000000b | prot: 0x1 | flags: 0x2 | status: 0x41 | fd: 0xffffffffffffffff | } Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Tikhomirov Pavel authored
Signed-off-by:
Tikhomirov Pavel <snorcht@gmail.com> Signed-off-by:
-
Tikhomirov Pavel authored
Signed-off-by:
-
Cyrill Gorcunov authored
We're aligning members and number in protobuf files from the very beginning for readability sake. So fix up newer ones which were not. Also use /* */ comments, not //. Signed-off-by:
-
Kir Kolyshkin authored
setup_opts_from_req() prints an error message, so there's no need for its caller to print another one. While at it, simplify/unify error checking, treating any non-zero value as an error. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
-
Adrian Reber authored
Using a soname makes it easy for applications to detect if the ABI of libcriu.so has changed. It still creates libcriu.so as before in lib. During 'make install' additional links are created: libcriu.so -> libcriu.so.1.0 libcriu.so.1 -> libcriu.so.1.0 Signed-off-by:
-
Tikhomirov Pavel authored
Signed-off-by:
-
Andrey Vagin authored
CONFIG_HAS_PEEKSIGINFO_ARGS is used there. Cc: Christopher Covington <cov@codeaurora.org> Reported-by:
-
Kir Kolyshkin authored
For x86_64, LIBDIR can be tricky to find out. Nevertheless, this works for at least RedHat/CentOS/Fedora, SLES/openSUSE, Debian/Ubuntu and Gentoo. So, while it can guess LIBDIR wrong, this is still a good approximation for those installing criu from source. Signed-off-by:
-
