- 01 Nov, 2013 11 commits
-
-
Alexander Kartashov authored
It has been a mistake to introduce this struct since the FPU state is stored deep inside an ARM sigframe. A remnant of the struct is left to make the code compatible with the universal declaration of the routine sigreturn_prep_fpu_frame(). Signed-off-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Alexander Kartashov authored
The ARM VFP header is a part of the VFP frame that makes it unreasonable to have frame initialization split into two routines. This patch moerges the ARM version of the routine sigreturn_prep_fpu_frame() into restore_fpu() and reduces the former into a stub. Signed-off-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Alexander Kartashov authored
The routine restore_fpu() contains two bugs: 1) it reads more bytes from the array ThreadInfoArm::fpstate::vfp_regs than it actually containes; 2) the value of the field ThreadInfoArm::fpstate::fpscr is dropped on the floor. Signed-off-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Alexander Kartashov authored
It turned out that AArch64 uses the UAPI syscall numbering scheme that is incompatible with x86. Unfortunately this kills the idea of the unified syscall table and syscall generator. Note that the following syscalls: * open, * mkdir, * rmdir, * unlink, are declared obsolete in the UAPI. Moreover the syscall arch_prctl doesn't exist in the UAPI. Signed-off-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Alexander Kartashov authored
Signed-off-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Alexander Kartashov authored
An fpu_state_t instance shouldn't be stored in an ARM sigframe that makes it necessary to generalize the way the FPU state is accessed in the routine construct_sigframe() Signed-off-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Alexander Kartashov authored
This patch introduces the routines ptrace_get_gpregs() and ptrace_set_gpregs() that wrap the ptrace interface to get and set CPU registers respectively. The motivation is to make the CRIU code be compatible with architectures that don't support the PTRACE_GETREGS and PTRACE_SETREGS ptrace calls --- the requests PTRACE_GETREGSET and PTRACE_SETREGSET are implemented instead. Signed-off-by:
Alexander Kartashov <alekskartashov@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Required for simpler next patching. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
In case if checkpoint is failed or -R option passed we need to remove link remap files created during dump procedure. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
It's been found that if -R (leave task running after checkpoint) option passed we don't unlock network, nether we clean service files (such as link remaps). After a long discussion we choose the following path: if -R option is passed, it means a user is quite confident in what he is doing and consistency of the resources (file system) is achieved by a user himself with help of post-dump script. Also a user knows that the network will be unlocked and accept such case. So here we check of -R being passed in command line and once checkpoint complete we unlock the network. Cleaning up of link remaps is addressed in another patch. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 31 Oct, 2013 4 commits
-
-
Andrey Vagin authored
Currently if a network namespace is dumped and something fails, sockets remain in repair mode. It's because cpt_unlock_tcp_connections is executed only if network namespace is not dumped. cpt_unlock_tcp_connections disables repair mode for sockets and drops netfilters. netfilters are not used in case of network namespaces. v2: don't execute network-unlock scripts, if network namespace are not dumped. Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Ruslan Kuprieiev authored
These are inherited from parent on fork(), thus need to put them in clean state. Signed-off-by:
Ruslan Kuprieiev <kupruser@gmail.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Ruslan Kuprieiev authored
Signed-off-by:
Ruslan Kuprieiev <kupruser@gmail.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 30 Oct, 2013 7 commits
-
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
The only place left, that runs parasite by hands -- unmap(). Now we can use parasite_run() for that. 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>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
This one keeps registers and sigmask for running thread. Will be used for simpler parasite management. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
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>
-
- 29 Oct, 2013 6 commits
-
-
Pavel Emelyanov authored
The ctl->sig_blocked in this place is the same as sigframe's one, as ctl's one was copied into sigframe's few steps before. 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>
-
Pavel Emelyanov authored
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>
-
- 28 Oct, 2013 1 commit
-
-
Andrey Vagin authored
If parasite exited unexpectedly, CRIU gets SIGCHLD and handles it. In sigchld handler we need to wait any child process. Currently criu waits neighbours in its group, but a dumped processes is in another group usually. Here is a typo. Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 18 Oct, 2013 1 commit
-
-
Pavel Emelyanov authored
As planned, this was bugfix-mainly release. However, some new features were added. Looking forward the v1.0 release :) Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 17 Oct, 2013 2 commits
-
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
There can be a more sophisticated security policy, but right now generic non-root user doesn't have any bits in there, so requiring them to be zero is a sane starting point. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 15 Oct, 2013 8 commits
-
-
Pavel Emelyanov authored
There's ... a number of places where we want to do something with /proc/self/fd/%d path. Each time we guess buffer size that is enough for this. Make standard constant for this and save some space on stack and drop args for some functions. 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>
-
Pavel Emelyanov authored
CRIU puts wd-s for one inotify in one row (one after another), so when collecting next wd, we can find the ify to attach them to faster. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
The inotify_add_watch generates wd-s one-by one. We cannot request for one, thus we call this syscall till the required wd is generated. Thus, if we want to restore several wd-s for an inotify, we have to put them in ascending order. Otherwise we may restore watch with higher wd earlier and will thus not be able to generate the lower wd in a reasonable time. 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>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-