crtools: preload libraries (v2)

Libraries (plugins) is going to be used for dumping and restoring
external dependencies (e.g. dbus, systemd journal sockets, charecter
devices, etc)

A plugin can have the cr_plugin_init() and cr_plugin_fini functions for
initialization and deinialization.

criu-plugin.h contains all things, which can be used in plugins.

v2: rename lib to plugin
v3: add a default value for a plugin path.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
plugin: add a function to get a descriptor to the image dir

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
dump: don't restore a state of threads

It is not needed, because stat is a property of task,
so we can restore a state of task and it should be enough.

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

Currently all task are restored as alive, but stopped tasks
must be restored as stopped.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
seize: Add some comments about unseizing task

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
zdtm: add a new test, which creates and destroys threads

A thread can create another threads, if the number of threads is less
than the limit.

This test case is very useful to check criu freezer.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
mnt_tree_for_each_reverse(): init a variable

A warning catched by clang:

> > mount.c:869:71: error: variable 'progress' is uninitialized when used here
> >       [-Werror,-Wuninitialized]
> >   ...prev, MNT_WALK_NONE, fn, (struct list_head *) NULL, progress);
> >                                                          ^~~~~~~~
> > mount.c:802:4: note: expanded from macro 'MNT_TREE_WALK'
> >                         _prgs++;
> > \
> >                         ^
> > mount.c:867:14: note: initialize the variable 'progress' to silence this
> > warning
> >         int progress;
> >                     ^
> >                      = 0
> > 1 error generated.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
dump: rework freeze of threads

When we try to freeze threads, some of them can exit
and a few new ones can be born. Currently we unfreeze process free
int this case, so we have the same chance to failed in the next case.

I suggest to not unfreeze frozen threads, just try to update thread list
and freeze unfrozen threads.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
crtools: rework freeze of processes (v2)

Before this patch crtools freezes processes and if something is changed,
it unfreezes all processes and starts again from the beginning.

If if are going to dump fork-bomb, this method doesn't work. Because a
big tree is always changed.

We don't need unfreeze processes, which have been frozen and this patch
does that.

This patch uses depth-first search (DFS) for traversing a process tree.

A root task is frozen at first turn, than a child is frozen, than a
child of child and so on.

When all children of one process are frozen, criu reads the list of
children again and check that nothing changed. This processes continues
until all of them will not be frozen. Afte that a new child can not be
appeared, because all children for children are frozen too.

v2: add comments in code
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
dump: try to stop a task as soon as possible

We read /proc/pid/status to determine a task state, but if a task is
running in this moment, its state may be changed.

This patch stops tasks before reading their /proc/pid/status

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
unix: link a socket to its peer

We are going to add callback-s for dumping external sockets.
All external sockets are added into unix_list, but for dumping we need
to know all peers.

And one more thing is that a socket is not closed before its peer is
not be dumped. We are going to transfer the socket decriptor in the
callback.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
sk-unix/dump: allocate UnixSkEntry dynamically

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
unux: postpone dumping sockets v2

Unix sockets are dumped, when a peer socket is found.
We are going to dump external sockets with help plugins. For the we need
to set the USK_CALLBACK flags in unix entry. Currently a socket is
dumped immediately when it's transfered, but we can be sure that a
socket is not external, only when we have its peer.

v2: add comments in code
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
unix: add ability to set callbacks for external sockets (v5)

We don't know a state behind an external socket. It depends on logic
of the program, which handles this socket.

This patch adds ability to load a library with callbacks for dumping
and restoring external sockets.

This patch introduces two callbacks cr_plugin_dump_unix_sk and
cr_plugin_restore_unix_sk. If a callback can not handle a socket, it
must return -ENOTSUP.

The main questions, what kind of information should be tranfered in
these callbacks. Pls, think a few minutes about that and send me
your opinion.

v2: Use uflags instread of adding a new field
v3: clean up
v4: Unsuitable callbacks return -ENOTSUP.
v5: set USK_CALLBACK, if a socket was dumped by callback.

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
tests: check callback-s for dumping and restoring sockets (v2)

Here are client, server programs and two libraries for dumping client
sockets and syslog socket.

The client can ask server to save a value and then request it later.
We suppose that after dumping and restoring the client will get
the same value.

So the dump callback requests the value and save it in a file.
The restore callback creates a new socket and ask server to save the
value from the file.

v2: open a syslog socket

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