Skip to content

C
criu
Switch branch/tag
  1. 20 Dec, 2013 10 commits
    • Andrey Vagin's avatar
      files: add ability to set callbacks for files (v7) · 6bbdec26
      Andrey Vagin authored 
      Here is nothing interecting. If a file can't be dumped by criu,
plugins are called. If one of plugins knows how to dump the file,
the file entry is marked as need_callback. On restore if we see
this mark, we execute plugins for restoring the file.

v2: Callbacks are called for all files, which are not supported by CRIU.
v3: Call plugins for a file instead of file descriptor. A few file
descriptors can be associated with one file.
v4: A file descriptor is opened in a callback. It's required for
    restoring anon vmas.
v5: Add a separate type for unsupported files
v6: define FD_TYPES__UNSUPP
v7: s/unsupp/ext (external)
Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      6bbdec26
    • Andrey Vagin's avatar
      tests: check callback-s for dumping and restoring sockets (v2) · 1e4b8c8c
      Andrey Vagin authored 
      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: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      1e4b8c8c
    • Andrey Vagin's avatar
      unix: add ability to set callbacks for external sockets (v5) · 9e3f4451
      Andrey Vagin authored 
      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: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      9e3f4451
    • Andrey Vagin's avatar
      unux: postpone dumping sockets v2 · afc61ba5
      Andrey Vagin authored 
      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: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      afc61ba5
    • Andrey Vagin's avatar
      sk-unix/dump: allocate UnixSkEntry dynamically · 59162ccc
      Andrey Vagin authored 
      Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      59162ccc
    • Andrey Vagin's avatar
      unix: link a socket to its peer · 8f66bf97
      Andrey Vagin authored 
      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: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      8f66bf97
    • Andrey Vagin's avatar
      dump: try to stop a task as soon as possible · dc914912
      Andrey Vagin authored 
      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: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      dc914912
    • Andrey Vagin's avatar
      crtools: rework freeze of processes (v2) · bf678790
      Andrey Vagin authored 
      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: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      bf678790
    • Andrey Vagin's avatar
      dump: rework freeze of threads · 978badc1
      Andrey Vagin authored 
      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: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      978badc1
    • Kir Kolyshkin's avatar
      mnt_tree_for_each_reverse(): init a variable · e2a0be63
      Kir Kolyshkin authored 
      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: 's avatarKir Kolyshkin <kir@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      e2a0be63
  3. 19 Dec, 2013 6 commits
  5. 18 Dec, 2013 24 commits