dump: clean up shared_fdtable

It's cleaned up accoding with following statements:
* files_id can't be zero (look at dump_task_kobj_ids)
* item->ids is allocated for all non-dead tasks
* a parent can't be dead

In addition here is a tiny coding stype fix.

Fixes: 475bb1e77522 ("rst: Evaluate per-task clone mask early")
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
test: clean the "test" directory from test/Makefile

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
test: don't clean up submounts (v2)

I'm scared, when I see smth like that:
rm: cannot remove ‘/var/lib/jenkins/jobs/CRIU/workspace/test/dump/static/cgroup00/31195/1/.criu.cgyard.6qctPl/systemd/tasks’: Operation not permitted

v2: do that only in the "test" directory

Reported-by: Mr Jenkins
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
fsnotify: open mount point relative to a proper root

Each mountpoint belongs to a mount namespace, so we need to
find a root of the mount namespace and open mountpoint
ralative to this root.

The same logic is used in get_mark_path().

Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
zdtm: chech that a mark is restored on a correct mount point

We try to remove mark on the correct mount point and
if the mark is restored on a wrong mount point, we will get ENOENT.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
zdtm/fanotify00: use /tmp instead of /

Usually /tmp is a mount point.

Recently we found a bug in criu, when it restore mount fanotify on "./"
instead of "/". The test didn't find it, because they are pointed on the
same mount point.

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