Before this patch only namespaces of the root task are dumped.
Now we dump all namespace, which have been collected.
I'm not sure, that we want to create a new process for each namespace.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Before we dumped namespace of the root task only.
Now we are going to dump nested namespaces, so we need to know a pid of
any process, which lives in the target namespace.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We are going to replace pid on id in names of image files. The id is
uniq for each namespace, so it's more convient, if image files are
opened per namespace.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We are going to replace pid on id in names of image files. The id is
uniq for each namespace, so it's more convient, if image files are
opened per namespace.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We are going to replace pid on id in names of image files. The id is
uniq for each namespace, so it's more convient, if image files are
opened per namespace.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We are going to replace pid on id in names of image files. The id is
uniq for each namespace, so it's more convient, if image files are
opened per namespace.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's preparation to replace pid on id in image names.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently all values of constants should be continuous,
because cr_fdset_open is used for opening images for all namespaces.
The next patches will rework this code and image files will be opened
per namespace, then all these ugly settings of one constant to another
will be removed.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently we catch processes on the exit point from sigreturn.
If a task must be restored in the stopped state, we can send SIGSTOP
before detaching from it.
v2: add more descriptive comment about skipping SIGSTOP in ptrace.c
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently we take pid and core from it and we are going to take state.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The kernel notifies about leaving syscall before starting to deliver
signals. If you don't believe me, pls look at arch/x86/kernel/entry_64.S:
int_ret_from_sys_call
syscall_trace_leave
do_notify_resume
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Everything in the sk-unix.c is ready for seq-packet sockets.
Signed-off-by: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In case criu and dumpee live in the same mount namespace there's no
need in getting ns' root from init task. We can get it from criu and
(!) void the root == "/" check, required for namespace case.
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 can restore task's pgid which is not equal to its pid,
only when the respective group leader is alive. To make
restore reliable we wait for all group leaders to restore
using separate restore stage.
It's better to optimize this -- each task has a pointer on
its group leader and waits for one to become such.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If a task opens a file, then goes chroot, CRIU should still
be able to dump and restore the now-invisible file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
First of all, this should be done strictly after we've stopped accessing
files by their paths, even absolute. This place is right before going
into restorer.
And the second thing is that we want to re-use the open_fd_by_id engine,
since it handles various tricky cases of open-file-by-path. And since
there's no such thing as fchroot(int fd), we emulate it using the
/proc/self/fd/ links.
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>
The register R12 has a special meaning when syscalls are hooked
with ptrace() in ARM that results in a dumpee context corruption
on an injected blob unmap. Note that this patch doesn't solve
the problem entirely since the compiler may corrupt the register
before issuing a call to the routine sys_munmap(); however
we assume that a sufficiently decent compiler doesn't.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Tested-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
I don't know a reason, when accept() fails once and then goes back to
normal work.
Cc: Ruslan Kuprieiev <kupruser@gmail.com>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
