This patch splits the file arch/x86/vdso-pie.c into machine-dependent
and machine-independent parts by moving the routines vdso_fill_symtable(),
vdso_proxify(), and vdso_remap() to the file pie/vdso.c.
The ARM version of the routines is moved to the source pie/vdso-stub.c
to provide the vDSO proxy stub implementation for architectures
that don't provide the vDSO.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Looks-good-to: Cyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Supported machine architectures provide TLS stogares of different sizes:
the size of the TLS storage in x86-64 is 24 bytes, ARM --- 4 bytes
and upcoming AArch64 --- 8 bytes. This means every supported architecture
needs a specific type to store the value of the TLS register.
This patch reworks the insterface of the routines arch_get_tls()
and restore_tls() passing them the TLS storage by pointer
rather than by value to simplify the TLS stub for x86.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The pie.lds.S.in needs two minor changes to work with the gold (/usr/bin/gold)
linker. These changes are compatible with /usr/bin/ld and make linker script
more portable.
The first change is adding a comma before /DISCARD/ so that the grammar
won't be ambiguous. A Otherwise, gold treats it as a part of the assignment
and would generate a syntax error about the "unexpected ':'".
The second change is moving initialization of __export_parasite_args
to inside the SECTIONS command because it references the dot symbol.
Otherwise, gold would generate the error "invalid reference to dot
symbol outside of SECTIONS clause.
Signed-off-by: Saied Kazemi <saied@google.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To be able to profile CRIU with gprof support we need a special flag
passed to the compiler and linker. But same time we can't build parasite
code with prof support because it'll call for mcount() service routine
for which we don't have any stub yet (and even if we had there are
other tech details involved). Thus PIE code won't be profiled.
To compile with prof support make it as
make DEBUG=1 GMON=1
The idea to run gprof then over criu sources. Once you've it
compiled with the flags mentioned above -- simply run it (test or whatever,
I've been running sh test/zdtm.st static.maps00).
Then run gprof ./criu gmon.out
Note the gmon.out file lays in directory where criu were running, thus
in case of sh test/zdtm.st static.maps00 the output file will be in test/
directory.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
make engine will be reworked to clean up only those
files which were generated with implicit rules. Thus
anything generated in specific way must be cleaned
up explicitly.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Remove space before tab characters.
Found by git grep ' ' (Space, Ctrl-V, Tab in shell).
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Remove whitespace at EOL (found by git grep ' $')
To people using vim, I'd suggest adding the following code to ~/.vimrc:
let c_space_errors = 1
highlight FormatError ctermbg=darkred guibg=darkred
match FormatError /\s\+$\|\ \+\t\|\%80v.\|\ \{8\}/
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Move prctl constants into own header. They are
arch independent.
The x86 specific ARCH_SET_GS should be fetched from <asm/prctl.h>
(instead of defining own ones).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This limit is not exported by a kernel, so no need
to "explicitly" define it pretending that it's immutable.
Still I kept this name in comment just to give reader
a tip where CR_SCM_MAX_FD came from.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
fcntl data is arch independent, so move it out of include/asm/type.h
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This actually fixes a bug -- memory for shmem info was
not allocated dynamically, thus we were limited in the
amount of shmems to be restored.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In case if we need to use vdso proxy the memory area
which holds restorer also has a place for vdso proxy
code itself, so on final pass we should not unmap it,
otherwise any call to vdso function will cause sigsegv.
IOW, the memory before final "cleanup" pass of restorer
might look as
+-----------+---------+ +-------------+------+
| bootstrap | rt-vdso | ... | application | vdso |
+-----------+---------+ +-------------+------+
^ |
`-------------------------+
and we have redirected "vdso" code to jump to "rt-vdso".
After final pass the memory must look as
+---------+ +-------------+------+
| rt-vdso | ... | application | vdso |
+---------+ +-------------+------+
^ |
`-------------------------+
I noticed this problem during container migration
testing, the container itself was suspended on 2.6.32
OpenVZ kernel with apache running inside, and any attempt
to connect to apache caused apache to crash.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In case if we hit error returned from syscall, better
to print error code for easier understanding of the
protblem.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We use unix socket to communicate with parasite. Before we used
SOCK_STREAM, but it doesn't guaranty that the message boundaries will be
save.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We cannot fail at that late stage, as everything is restored
and running. In the worst case (unmap fails) restored task would
have one extra mapping.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We restore chroot before doing this, so if we might need to
open one, we may have no access to the /proc/... paths.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
All process VMA-s are in "premmaped area". All restorer stuff are in
bootstap "area", so we have two areas.
So we don't need to unmap extra VMA-s one by one. We can call munmap
three times for the region before the first area, for the hole between
areas and for the region after the second area.
The old scheme didn't work, because the list of VMA-s can be changed
after collecting. It can be due to memory allocations by libc or due to
increased stack.
v2: improve readability at the expense of beautiness
v3: print return code of munmap in error messages
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch adds a new parasite command, which unmaps the parasite blob.
This command never returns and the criu process traps the target process
on the exit from the munmap syscall.
v2: rename the function for unmaping a parasite blob to not intersects
with criu's functions.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch adds a function for removing the restorer blob. This function
never returns and the process must be trapped on the exit from the
munmap syscall.
v2: * release parasite_ctl sturcture and use the new interface of
parasite_prep_ctl
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
pr_perror uses errno, which is set by glibc wrappers.
In pi return codes of syscalls should be printed
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We will need to reuse this code in criu library, where libc calls
are present thus we will be compiling it in shared mode.
Because internal syscalls library won't be needed we wrap them
with __sys macro which would hide the details of invocation depending
on CR_NOGLIBC preprocessor variable passed from command line.
Original-patch-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This thing was introduced by 01f8f8f4 to help not mixing
per-thread error messages in log files. Now messages are
not mixed by other means, so this thing is useless.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There are parts dumping which is common to thread and task,
and this stuff is represented by parasite_dump_thread structure.
Merge this into parasite_dump_misc and facror out dumping code.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If a kernel supports PTRACE_SETSIGMASK, criu don't need to execute
PARASITE_CMD_INIT and PARASITE_CMD_DAEMONIZE, because the frist command
is used only for blocking signals. If criu crashes between these
commands, a process state will be corrupted, because all signals remain
blocked.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We use two commands to get task registers safely. The first command
blocked signals, then crtools dumped registers and all per-thread data
and the the second command unblocks signals.
Currently signals can be blocked with help SETSIGMASK, so we need only
one command to dump per-thread data.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The initilization stage is not good for that, because it can fail.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
[alekskartashov@: use encode_pointer]
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Alexander Kartashov <alekskartashov@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>