Skip to content

C
criu
Switch branch/tag
  1. 04 Aug, 2014 14 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 3 commits
    • Cyrill Gorcunov's avatar
      vdso: x86 -- Drop BUG_ON if no pfn found · e1b56c8f
      Cyrill Gorcunov authored 
      If pfn = 0 it means we hit something very strange
condition but better to not yield BUG_ON here,
better exit with error for future investigation.
Signed-off-by: 's avatarCyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      e1b56c8f
    • Andrey Vagin's avatar
      jenkins/btrfs: exclude inotify_irmap · 828715f9
      Andrey Vagin authored 
      Cyrill:  we exclude these tests because of braindamaged scheme
         btrfs uses for subvolume device numbering which we don't
	 yet support in inrmaps.

Test: zdtm/live/static/inotify_irmap, Result: FAIL
==================================== ERROR ====================================
Test: zdtm/live/static/inotify_irmap, Namespace: 1
Dump log   : /mnt/btrfs/workspace/test/dump/inotify_irmap/16077/1/dump.log
--------------------------------- grep Error ---------------------------------
(00.024342) Error (irmap.c:80): irmap: Can't stat /var/spool: No such file or directory
(00.024365) Error (irmap.c:80): irmap: Can't stat /lib/udev: No such file or directory
(00.024378) Error (irmap.c:80): irmap: Can't stat /no-such-path: No such file or directory
(00.024383) Error (fsnotify.c:184): fsnotify: Can't dump that handle
(00.024397) Error (cr-dump.c:1563): Dump files (pid: 16090) failed with -1
(00.024779) Error (cr-dump.c:1911): Dumping FAILED.
------------------------------------- END -------------------------------------
================================= ERROR OVER =================================
Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      828715f9
    • Andrey Vagin's avatar
      test/jenkins: add job to test pre-dump · 77391fa7
      Andrey Vagin authored 
      Make pre-dump twice and then dump and restore.
Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      77391fa7