ptrace: don't call PTRACE_INTERRUPT many times

According to the commit message in the kernel git, a new trap flag
JOBCTL_TRAP_INTERRUPT is added, which is set on PTRACE_INTERRUPT and
cleared when any trap happens.

Currently we have a race window beetwen PTRACE_CONT and
PTRACE_INTERRUPT. If a process stops before PTRACE_INTERRUPT,
the flag JOBCTL_TRAP_INTERRUPT will be set once again.

https://bugzilla.openvz.org/show_bug.cgi?id=2569

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
mem: Treat /proc/pid/pagemap2 file as optional

It will appear not earlier than in 3.10.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
check: Warn *diag absense always

To know what exactly is missing.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
check: Introduce --ms option

This option skips checking for features, that are known to
be absent in mainstream kernel.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
tools

Signed-off-by: Andrey Vagin <avagin@openvz.org>
newpidns
zdtm: execite test cases from a test user

Signed-off-by: Andrew Vagin <avagin@openvz.org>
socket-ext: provide access to socket for a test user
zdtm: wait all children during cleaning up
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>

Conflicts:
	cr-dump.c
	include/pstree.h
	pstree.c
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>

Conflicts:
	arch/arm/crtools.c
	arch/x86/crtools.c
	include/parasite-syscall.h
	parasite-syscall.c
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>

Conflicts:
	pie/parasite.c
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>

Conflicts:
	parasite-syscall.c
	pie/parasite.c
parasite: use a propper command for getting ack