syscall: don't use pr_info to print a part of string

Before:
(00.009468)     87: sysctl: <kernel/sem> = <(00.009475)     87: 2108913153 (00.009481)     87: 1252387386 (00.009486)     87: 835139248 (00.009491)     87: 320896030 (00.009496)     87: >
After:
(00.009468)     87: sysctl: <kernel/sem> = <2108913153 1252387386 835139248 320896030 >

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
zdtm/ipc_namespaces: don't extra symbols in a sysctl file

The kernel has a bug in handling auto_msgmni and if we send extra
symbols, a new value isn't applied.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
ipc: set the msgmni sysctl after auto_msgmni

Because setting of auto_msgmni recalculates a value of msgmni

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
sysctl: don't write '\0' at the end of buffer in a sysctl file

It isn't required. The kernel has a bug in handling auto_msgmni and
if we send extra symbols, a new value isn't applied.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
zdtm/ipc_namespace: set the auto_msgmni sysctl to zero

We are going to execute tests concurrently, but if auto_msgmni is
enabled, the msgmni is recalcalated each time, when ipcns is created
or removed.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
restore: --restore-detached implies CLONE_PARENT

We need to use CLONE_PARENT to prevent processes from immediately dying due to
pdeath_sig when they are restored in detached mode.

[ xemul: One more place which requires check for restore-detach
         is in sigactions preparation ]

Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
cg: Fix restoration of tasks into existing cgroups

When we omit the --manage-cgroups on dump the controllers section
in cgroups image lacks the none-d entries (the name=systemd is the
most typical).

If it happens, that init task lives in non-criu cgset (it can be
so if we do --shell-job dump from another terminal and see criu
and root task living in different user.slice systemd cgroups) then
on restore the move_in_cgroup() would fail to lookup the required
controller.

In order to fix this we should still call the collect_cgroups()
on dump, so that it adds the none-d controllers into the list,
but don't dump the dirs tree itself.

The patch looks ugly, but it just moves the current_controller
evaluation from the middle of the loop upwards (and renames the
char *opts variable not to conflict with global opts).

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
cg: Use relative paths in cgroup dirs image

Before the patch cg tree section from cgroup00 test looked like this

{
	cnames: "name=zdtmtst"
	dirs: 	{
		path: "/subcg"
		children: 		{
			path: "/subcg/subsubcg"
			children: <empty>
			properties: <empty>
		}

		properties: <empty>
	}

}

this /subsg in the children is excessive. Turn this into directory names.
Now the section looks like

{
	cnames: "name=zdtmtst"
	dirs: 	{
		dir_name: "subcg"
		children: 		{
			dir_name: "subsubcg"
			children: <empty>
			properties: <empty>
		}

		properties: <empty>
	}

}

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
criu: allow the root task to handle SIGCHLD

If criu process attaches to the root task (it happens for opts.swrk_restore
and opts.restore_detach) with ptrace, then any signal delivered to the root
would be also delivered to criu. The latter woult treat the former to die
due to this delivery and would abort the restore.

Fix it by checking that criu (current == NULL) gets ptrace notification
(si_code == CLD_TRAPPED) about signal delivered (si_status = SIGCHLD,
no other signals are allowed by the restoring tasks).

This patch fixes the following error of static/zombie00:

Execute zdtm/live/static/zombie00
./zombie00 --pidfile=zombie00.pid --outfile=zombie00.out
Dump 2207
Restore
Test: zdtm/live/static/zombie00, Result: FAIL
==================================== ERROR ====================================
Restore log: /root/git/orig/criu/test/dump/static/zombie00/2207/1/restore.log
(00.026826) Error (cr-restore.c:1085): 2207 killed by signal 17
(00.026985) Error (cr-restore.c:1706): Restoring FAILED.
================================= ERROR OVER =================================

Reported-by: Mr Jenkins
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
zdtm: add a small program to create a zdtm container (v2)

I didn't find a way how to do that with help "unshare".
It's simpler to write this program. It looks better than tricks in
zdtm.sh.

v2: proxify exit status

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Ruslan Kuprieiev <kupruser@gmail.com>
Acked-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
restore: Set CLONE_PARENT iif pdeath_sig is present, v4

It's been discovered that on 3.11 we might fail on restore
if pass @CLONE_PARENT flag into clone() call due to kernel
limitations.

Because we're treating 3.11 as a base working kernel lets
do a trick instead

 - setup this flag iif pdeath_sig is present
 - if CLONE_NEWPID is passed warn a user about
   potential consequences.
 - because we need to carry the condition in attach_to_tasks
   call, introduce @root_as_sibling variable for this.

CC: Tycho Andersen <tycho.andersen@canonical.com>
CC: Pavel Emelyanov <xemul@parallels.com>
CC: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
tty: open tty-s with O_NOCTTY

When we open tty, we don't want to set it as controlling terminal.

[xemul: We do it in all the other places, this one is forgotten.
 The "controlling tty" feature is setup explicitly later with
 the ioctl (TIOCSCTTY) call. ]

This bug was caught by pty04. Where we get unexpected SIGCONT,
which is sent after closing a controlling terminal.

./pty04 --pidfile=pty04.pid --outfile=pty04.out
Dump 9578
Restore
Test: zdtm/live/static/pty04, Result: FAIL
==================================== ERROR ====================================
Test: zdtm/live/static/pty04, Namespace:
Dump log   : /home/jenkins/workspace/Rpi-CRIU/test/dump/static/pty04/9578/1/dump.log
--------------------------------- grep Error ---------------------------------
------------------------------------- END -------------------------------------
Restore log: /home/jenkins/workspace/Rpi-CRIU/test/dump/static/pty04/9578/1/restore.log
--------------------------------- grep Error ---------------------------------
(00.083420) Error (cr-restore.c:1092): 9578 killed by signal 0
(00.083708) Error (cr-restore.c:1713): Restoring FAILED.
------------------------------------- END -------------------------------------
================================= ERROR OVER =================================

Reported-by: Mr Jenkins
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
cg: path buffer should be PATH_MAX long

Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
wip
wip