- 29 May, 2013 1 commit
-
-
Cyrill Gorcunov authored
While being extracting common part of image descriptors to separate file this declaration escaped me. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 28 May, 2013 4 commits
-
-
Cyrill Gorcunov authored
Move image object descriptors to own image-desc file(s). This allow to reuse the code in other tools. I had to move show declarations to cr-show.h as well. Signed-off-by:
-
Cyrill Gorcunov authored
Move protobuf object descriptors to own protobuf-desc file(s). This allow to reuse the code in other tools. Signed-off-by:
-
Andrey Vagin authored
Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Pavel Emelyanov authored
We have global instance of them, that's enough. Signed-off-by:
-
- 27 May, 2013 9 commits
-
-
Andrey Vagin authored
It was required for daemonized threads. Signed-off-by:
-
Andrey Vagin authored
Signed-off-by:
-
Andrey Vagin authored
For dumping thread we need to execute only one command, so its demonization is overload. Signed-off-by:
-
Andrey Vagin authored
Currently we use id to get pid and other properties, which used when a thread is daemonized. We are going to not demonize threads, so pid will be only one useful field on parasite_thread_ctl. Signed-off-by:
-
Andrew Vagin authored
regs_orig is a pointer on struct user_task_regs Signed-off-by:
-
Andrey Vagin authored
Use original registers, which belong to the executing thread. Signed-off-by:
-
Cyrill Gorcunov authored
rhel6 compiler is not happy about preliminary declaration of VmaEntry type yielding error on building attempt, thus include protobuf header. Signed-off-by:
-
Cyrill Gorcunov authored
Otherwise when get used outside of criu code | ../../arch/x86/include/asm/fpu.h:98:2: error: unknown type name ‘bool’ Signed-off-by:
-
Cyrill Gorcunov authored
Otherwise kernel is not happy with attempt to write rx only memory, causing dumpee to fail on restore. Signed-off-by:
-
- 24 May, 2013 26 commits
-
-
Andrey Vagin authored
Signed-off-by:
-
Andrey Vagin authored
This patch reduces a window, when a crtools can kill a dumped process, because if a parasite in a deamon mode can restore the state of the process, if crtools detached unexpectedly. All threads are synchronized on the _exit_ point from sys_rt_sigreturn, for that crtools traces all syscalls. After that we remove the parasite blob from dumpee as we did it previously and let the process run further. Signed-off-by:
-
Andrey Vagin authored
We're about to implement functionality to allow parasite to return to dumpee via sigreturn in case crtools suddenly detached from it. Thus, we need a space for sigframe in shared area. Signed-off-by:
-
Andrey Vagin authored
This mask should be put into sigframe (used by parasite, coming soon) thus we have to pull one from dumpee early. Plus, check that signals are blocked for each thread separately Signed-off-by:
-
Andrey Vagin authored
Parasite daemon mode it quite tricky. One may consider it as consisting of two parts - daemon mode for thread leader - daemon mode for regular threads Thread leader daemon -------------------- Once thread leader parasite code switched initialized, it starts spinning on socket listening for commands to handle. If the command destination is the thread leader itself it handles it and replies back the ack to the caller (iow the main crtools code). If the recepient is not thread leader but one of threads, then thread leader wakes up the thread by futex and makes it to handle the command waiting on futex for result. Once result obtained, the ack is being sending back to caller. Thread daemon ------------- On initialization thread daemon starts waiting a command on futex. The futex is triggered by thread leader daemon when command received. Once command is received and handled, the result is reported back to the thread leader daemon, which in turn send ack message. Both thread-leader and regular threads require own stack to operate on since they all are present in memory simultaneously. Thus we use call_daemon_thread() helper which takes care of providing stack to the callee. TODO: - ARM requires own wrappers on damonize/trap low-level code, at moment x86-64 is only covered v2: remove PARASITE_CMD_DAEMONIZED and s->ack parasite: use a propper command for getting ack Fixed-by: -
Cyrill Gorcunov authored
It's autogenerated file. Signed-off-by:
-
Cyrill Gorcunov authored
Parasite daemon mode might be considered as a series of network messages sent from main crtools module to parasite daemon which spins on a socket waiting for command to handle. Simple command handling session might look as crtools daemon | | | | ---> command message ---> | | | | ---> receive command ---> | | | .... | | | handle command | | | .... | | | <--- send ack <--- | | <--- receive ack <--- | | | | | v v v time where, in case of multithread application [handle command] stage includes waking up of children threads via futexes, wait until handling complete and only then send ack back to ctrools module. This patch brings in description of command message as struct ctl_msg { unsigned int id; /* command recipient */ unsigned int cmd; /* command itself */ unsigned int ack; /* ack on command */ int err; /* error code on reply */ }; For example, in case of dumpee being with pid 2 and acquiring to handle PARASITE_CMD_DUMP_MISC, the command/ack series will look as cmd-msg ------- .id = 2, .cmd = PARASITE_CMD_DUMP_MISC, .ack = 0, .err = 0, ack-msg ------- .id = 2, .cmd = PARASITE_CMD_DUMP_MISC, .ack = PARASITE_CMD_DUMP_MISC, .err = 0 in case if error happened in parasite, the @err field set accordingly. For convenience ctl_msg_cmd()/ctl_msg_ack() macros are provided for control message generations. v2: delete futex_t ack from tid_state_s Fixed-by: -
Cyrill Gorcunov authored
They are relying on trap being issued at the end of execution so to distinguish it with future daemon mode add "trap" postfix to them. Signed-off-by:
-
Andrey Vagin authored
Otherwise a task can start to handle a signal and registers can be changed. Signed-off-by:
-
Andrey Vagin authored
When we try to execute a parasite code, a signal can be started handling, so we need to update a task registers, which will be saved in a core file. Signed-off-by:
-
Andrey Vagin authored
Currently it's always stopped, but it will be changed, when a parasite will be executed as a daemon. Signed-off-by:
-
Andrey Vagin authored
It will be used for executed parasite as a daemon. What we have previously -- the stack has been preallocated in parasite blob itself and bootstrap procedure calculated the value needed for %rsp. With this patch applied we provide every thread own stack as: - find out how many threads are present - calculate the summary size of all stacks - when we ask dumpee to provide us memory area needed to run parasite code, we pass summary size needed for everything - when parasite code is asked to run we calculate %rsp needed taking into account the thread number (ie offsets) and then setup proper %rsp via ptrace call, instead of calculating it in bootstrap parasite code Signed-off-by:
-
Andrey Vagin authored
Now we restore thread registers immediately after a command, but when we will execute a parasite, it will be impossible. Signed-off-by:
-
Andrey Vagin authored
We have three arrays for thread related data: item->threads, parasite_ctl->thread and tid_state in parasite. With this patch a thread will have the same index in all arrays. The zero index is used for a thread leader. In this case we don't need to search thread_state in parasite. Signed-off-by:
-
Cyrill Gorcunov authored
When parasite daemon mode will be implemented we get deprived of ability to fetch registers at the late moment of dumping as we were, thus just bind CoreEntry to pstree item and allocate CoreEntry'ies for every thread found, once process tree is in seized state. Then immediately fill CoreEntry'ies with registers. We use prctl opcode for that but fetch a complete set of registers including FPU state, and convert them into protobuf format. Zombie tasks remains untouched, we allocate CoreEntry for them right at moment of dumping becuase we don't need registers there to be written on disk. This way get_task_regs no longer need parasite_ctl argument and it's zapped. Still parasite_ctl has own copy of general registers set but this is because we need them to be in cpu native format unlike ones kept in CoreEntry. Signed-off-by:
-
Andrey Vagin authored
Before this patch sigframes were constructed in restorer. We are going to construct sigframes for parasites. Both parasite and restorer should be as thing as posible. Signed-off-by:
-
Andrey Vagin authored
Signed-off-by:
-
Andrey Vagin authored
The first one fills sigframe and the second one restores another registers. Signed-off-by:
-
Andrey Vagin authored
struct thread_restore_args contains many pointers on different objects, only a few of them are really required. Signed-off-by:
-
Andrey Vagin authored
Wait while futex @f value is equal to @v Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Instead of opencoded mark injection provide a helper for easier grepability. [xemul: Go ahead and remove the INIT_VDSO_MARK at all] Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by: -
Cyrill Gorcunov authored
The [vdso] mark in procfs output is not reliable, so since we know which prot it should has, escape obvious mishints. Signed-off-by:
-
Cyrill Gorcunov authored
In case if we have created vdso proxy the rt-vdso should not be dumped because it will be re-created on next restore anyway. Thus with help of parasite service routine find the rt-vdso and tear it off from VMAs list. Signed-off-by:
-
Cyrill Gorcunov authored
In case if we need vdso proxy there is a need to recognize it somehow on further checkpoint action. But such vdso won't be recognized by the kernel and [vdso] mark won't appear in procfs output. Thus we put own mark on it. Signed-off-by:
-
