Skip to content

C
criu
Switch branch/tag
  1. 04 Aug, 2014 9 commits
  3. 17 Jul, 2014 3 commits
  5. 16 Jul, 2014 2 commits
    • Andrew Vagin's avatar
      cgroup: don't look up existing mount point · dda742ec
      Andrew Vagin authored 
      A mount point, which is mounted by someone else, may be umounted in
any moment.

For example the test system executes tests concurrently and sometimes
one test looks up a mount point, which has been mounted by another test.

==================================== ERROR ====================================
Test: zdtm/live/static/inotify00, Namespace: 1
Dump log   : /var/lib/jenkins/jobs/CRIU-dump/workspace/test/dump/inotify00/15535/1/dump.log
--------------------------------- grep Error ---------------------------------
(00.021951) Error (cgroup.c:409): cg: failed walking /var/lib/jenkins/jobs/CRIU-dump/workspace/test/dump/signalfd00/15538/1/.criu.cgmounts.UGj28v/ for empty cgroups
(00.021967) Error (cr-dump.c:1601): Dump core (pid: 15535) failed with -1
(00.025509) Error (cr-dump.c:1914): Dumping FAILED.
------------------------------------- END -------------------------------------
================================= ERROR OVER =================================

In the previous patch I suggested to open a mount point, but it brought
other problems. We may open a directory where a cgroup mount has been
umounted and an owner will get EBUSY on attempt to remove this
directory.

Reported-by: Jenkins Criuovich
Acked-by: 's avatarTycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: 's avatarAndrew Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      dda742ec
    • Pavel Emelyanov's avatar
      cg: Don't walk cgroup tree when it's not required · 97f7d179
      Pavel Emelyanov authored 
      We have two bugs actually.

First, the check for 'item == root_item' in dump_task_cgroup fires
twice: first when we rite inventory (item == NULL as argument and
root_item == NULL because we haven't yet collected tasks) and the
2nd time when we dump the root task itself.

The 2nd issue sits in dump_cgroups() -- if root_cgset == criu_cgset
we don't write cgroups information at all (checking that we don't
have them with list_is_singular() inside that if). That said, we
don't need to read the cgroups tree if we're not going to dump it.

This patch fixes both.
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
Acked-by: 's avatarAndrew Vagin <avagin@parallels.com>
Acked-by: 's avatarTycho Andersen <tycho.andersen@canonical.com>
      97f7d179
  7. 15 Jul, 2014 4 commits
  9. 14 Jul, 2014 6 commits
  11. 11 Jul, 2014 7 commits
  13. 10 Jul, 2014 1 commit
    • Tycho Andersen's avatar
      Attempt to restore cgroups · 51876eea
      Tycho Andersen authored 
      During the dump phase, /proc/cgroups is parsed to find co-mounted cgroups.
Then, for each task /proc/self/cgroup is parsed for the cgroups that it is a
member of, and that cgroup is traversed to find any child cgroups which may
also need restoring. Any cgroups not currently mounted will be temporarily
mounted and traversed. All of this information is persisted along with the
original cg_sets, which indicate which cgroups a task is a member of.

On restore, an initial phase creates all the cgroups which were saved. Tasks
are then restored into these cgroups via cg_sets as usual.
Signed-off-by: 's avatarTycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      51876eea
  15. 08 Jul, 2014 5 commits
  17. 04 Jul, 2014 3 commits