x86: syscalls -- Add sys_sendto/sys_recvfrom helpers

Will be needed for parasite code.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
x86: parasite -- Add call_daemon_thread and asm_trap helpers

call_daemon_thread will be needed to run thread daemon
with own stack, while asm_trap is just a wrap over trapping
instruction for portability sake.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
pstree: Bind CoreEntry to pstree and fill it with registers early

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: Cyrill Gorcunov <gorcunov@openvz.org>
parasite-syscall: Add "trap" postfix to parasite execute functions

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: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: Extend tid_state_s structure

In daemon mode each thread will require own stack
to run on, thus add @stack member.

Also we will need an @real member to identify each
thread uniquely, @real stands here for "real" pid
which we refer to in main crtools module.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: Initialize tid_state_s::real on parasite bootstrap

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: Use thread state hash for fast lookup over thread state areas

We lookup for threads state via hash map, which makes fini
sequence to provide @real for parasite code.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: Prepare structures for daemon mode

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.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: Initialize @cmd/ack in init_thread

To not fail if one day PARASITE_CMD_IDLE become
non equal to zero.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: Switch parasite to daemon mode

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

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
parasite: use a propper command for getting ack
parasite: restore thread registers

crtools dump should not be destructive.

We suppose that item->threads[0] is a thread leader.
dump: block signals with help of ptrace

Currently crtools blocks signals from a parasite code, but for executing
the parasite code a process has to handle all pending non-blockedsignals.

It is not a problem until crtools decide to support stopped tasks.

Registers were saved before blocking signals, so a task can enter in a
signal hangler and block a part of signals, than it will be restored out
of signal handler with blocked signals.
parasite: remove extra synchronisation

crtools don't send a new command until it gets ack on a previous one.
restore: use a concrete object for constructing sigframe

struct thread_restore_args contains many pointers on different objects,
only a few of them are really required.
restore: add a function for constructing sigframe
restore: split restore_gpregs on two parts

The first one fills sigframe and the second one restores another
registers.
restore: construct sigframe in crtools

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.
dump: fill sigblock mask immediately after getting it

It will be used for constructing sigframe for parasite threads
dump: reseve space and construc sigframes for parasites