- 27 May, 2013 1 commit
-
-
Cyrill Gorcunov authored
Otherwise kernel is not happy with attempt to write rx only memory, causing dumpee to fail on restore. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 24 May, 2013 33 commits
-
-
Andrey Vagin authored
Signed-off-by:
Andrey Vagin <avagin@openvz.org> 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:
-
Cyrill Gorcunov authored
We will need it in parasite code to detect run time vdso area. Signed-off-by:
-
Cyrill Gorcunov authored
When a task being restored we may meet two situations - vdso in image doesn't match the runtime vdso provided by a kernel. For this case we need to patch dumpee vdso redirecting calls to runtime vdso, thus dumpee vdso become a proxy. - vdso in image does match the runtime vdso, in this case we simply remap runtime vdso to address where dumpee vdso lives. Plain remapping here is quite important and allows us to save vdso pfn which will be used in parasite code later. Note after this patch the restored task may have two vdso in memory. Proper dumping of such situation will be addressed in future patches. Signed-off-by:
-
Cyrill Gorcunov authored
Runtime vdso need to be kept in some safe place when all self-vmas are unmapped. So we reserve space for it in restorer blob area and then remap it into. It's quite important to do a remap here rather than data copy because otherwise pfn of vdso disappear and in future we won't be able to detect vdso are on dumping stage. Signed-off-by:
-
Cyrill Gorcunov authored
During criu startup we need to fill symbol table of own run-time vdso provided by the kernel. We will need this data for vdso proxy. Because this functions are not used in restorer code, we move them out of PIE (since PIE code must remain as small as possible). Signed-off-by:
-
Cyrill Gorcunov authored
It's quite minimal at moment and provides only two helpers - vdso_redirect_calls, to patch vdso area redirectling calls to some new place. - vdso_fill_symtable, to parse vma area as vdso library and fill symbols table with offsets and names. Because these routines will be needed in both regular criu code and restorer code -- we compile it in pie format. Signed-off-by:
-
Cyrill Gorcunov authored
Will need to extend it to support vdso-pie code which used in both -- pie code and plain executable code. I know it's ugly and I must invent some more elegant way, but need some solution at moment to be able to compile existing code. Signed-off-by:
-
Vladimir Davydov authored
With the patch zdtm will check not only periodic timers, but also one-shot ones. Set one-shot timer to expire in a very long interval (INT_MAX in the test), and check its remaining value after checkpoint/restore. The following relationship must hold: initial_value - remaining_value = time_passed Signed-off-by:
Vladimir Davydov <vdavydov@parallels.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
-
- 23 May, 2013 6 commits
-
-
Andrey Vagin authored
An archive is saved in unsuccessful case. Signed-off-by:
-
Andrey Vagin authored
It's optional. It's going to be used in jenkins. time bash -x test//zdtm.sh static/maps04 real 0m40.220s user 0m0.096s sys 0m12.822s time bash -x test//zdtm.sh -t static/maps04 real 0m9.904s user 0m0.074s sys 0m1.630s Signed-off-by:
-
Andrey Vagin authored
Here are a few bugs which hide each other. * memcmp(&newset, &oldset, sizeof(newset) returns 0 is masks are equal. * sigprocmask return sigset_t and it contains extra bits for the future, so we need to initialize all this bits otherwise they will contain random data. Signed-off-by:
-
Cyrill Gorcunov authored
Will need them in pie code soon. Signed-off-by:
-
Cyrill Gorcunov authored
There will be a couple of more builtin helpers needed in pie code soon. Thus to unify approach do - rename asm/memcpy_64.h to asm/string.h - introduce include/asm-generic/string.h file where all helpers are implemented if optimized variant is not yet provided Signed-off-by:
-
Cyrill Gorcunov authored
RHEL6 is shipped with libc 2.12 where no prlimit helper provided (which was pushed into libc itself since 2.13). So we implement own proxy for convenience. Note, if libc does support prlimit itself we simply don't use any proxy and call it directly. Signed-off-by:
-
