1. 17 Oct, 2017 5 commits
    • Andrei Vagin's avatar
      files: print an error if fdinfo can't be opened · d50f0e90
      Andrei Vagin authored
      Without this message, we don't know which fdinfo can't be opened.
      
      https://github.com/xemul/criu/issues/390Signed-off-by: 's avatarAndrei Vagin <avagin@openvz.org>
      Signed-off-by: 's avatarAndrei Vagin <avagin@virtuozzo.com>
      d50f0e90
    • Pavel Tikhomirov's avatar
      kdat: if iptables-restore has xtable lock support do wait on lock · ee7d3bec
      Pavel Tikhomirov authored
      On VZ7 we have a problem in random tests on iptables restore when
      running tests in parallel(one iptables-restore instance tries to lock
      xtables lock and fails while other instance(some iptables* command) is
      already holding the lock):
      
      ================== Run zdtm/static/socket_udp_shutdown in ns ===================
      Start test
      ./socket_udp_shutdown --pidfile=socket_udp_shutdown.pid --outfile=socket_udp_shutdown.out
      Run criu dump
      Run criu restore
      =[log]=> dump/zdtm/static/socket_udp_shutdown/77/1/restore.log
      ------------------------ grep Error ------------------------
      (00.158864)      1: 	Running ip rule delete table local
      (00.167319)      1: 	Running ip rule restore
      (00.175647)      1: 	Running iptables-restore for iptables-restore
      Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
      (00.185245)      1: Error (criu/util.c:719): exited, status=4
      (00.185289)      1: Error (criu/net.c:1739): iptables-restore failed
      (00.185301)      1: Error (criu/net.c:2382): Can't create net_ns
      (00.185370)      1: Error (criu/util.c:1412): Can't wait or bad status: errno=0, status=65280(00.187281) Error (criu/mount.c:2944): mnt: Can't remove the directory /tmp/.criu.mntns.Ai5EG9: No such file or directory
      (00.187298) uns: calling exit_usernsd (-1, 1)
      (00.187344) uns: daemon calls 0x466a40 (93, -1, 1)
      (00.187361) uns: `- daemon exits w/ 0
      (00.188375) uns: daemon stopped
      (00.188390) Error (criu/cr-restore.c:2450): Restoring FAILED.
      ------------------------ ERROR OVER ------------------------
      Test zdtm/static/socket_udp_shutdown FAIL at CRIU restore
      
      https://ci.openvz.org/job/CRIU/job/CRIU-virtuozzo/job/criu-dev/2873
      
      It happens now in every test-suit run on VZ7 host as we had updated to
      1.4.21-18 iptables package, which has patches for xlocks support in
      iptables-restore ported:
      
      * Mon Apr 24 2017 Thomas Woerner <twoerner@redhat.com> 1.4.21-18 - Add
      support for --wait options to restore commands (RHBZ#1438597)
      
      Whether these patches are ported to other distribution packages we'll
      have these problem in other distributions.
      
      Just add -w to wait lock on iptables-restore as older versions does not
      error on invalid option, just warning is printed.
      Signed-off-by: 's avatarPavel Tikhomirov <ptikhomirov@virtuozzo.com>
      Signed-off-by: 's avatarAndrei Vagin <avagin@virtuozzo.com>
      ee7d3bec
    • Kirill Tkhai's avatar
      net: Call ip[6]tables-restore with -w parameter · b2707bab
      Kirill Tkhai authored
      New ip[6]tables-restore utils has this parameter,
      which allows to wait for xtables lock, if it's
      occupied. When they don't wait, then the restore
      of iptables fails.
      
      Old versions just ignore this parameter
      with error in stderr, but it does not make them
      fail. So, pass it unconditionally.
      Signed-off-by: 's avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: 's avatarAndrei Vagin <avagin@virtuozzo.com>
      b2707bab
    • Mike Rapoport's avatar
      lazy-pages: consolidate error handling for uffdio_copy and uffdio_zeropage · f9170eff
      Mike Rapoport authored
      The errors set by both uffdio_copy and uffdio_zeropage are the same and
      require the same handling. Let's use a helper function to handle the errors
      returned by uffdio_copy and uffdio_zero.
      Signed-off-by: 's avatarMike Rapoport <rppt@linux.vnet.ibm.com>
      Signed-off-by: 's avatarAndrei Vagin <avagin@virtuozzo.com>
      f9170eff
    • Michael Holzheu's avatar
      zdtm/s390x_regs_check: Fix compiler warning · 7c0cedd8
      Michael Holzheu authored
      When running 'make zdtm' on s390x it fails on RHEL7 with:
      
       make[3]: Leaving directory `/tmp/criu/test/zdtm/lib'
        CC        s390x_regs_check.o
       s390x_regs_check.c: In function "util_hexdump_grp":
       s390x_regs_check.c:214:7: error: "ptr" may be used uninitialized
       in this function [-Werror=maybe-uninitialized]
          ptr += sprintf(ptr, "%02x", buf[i]);
      
      Fix this and assign ptr from the beginning to help gcc.
      Reported-by: 's avatarAdrian Reber <adrian@lisas.de>
      Signed-off-by: 's avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Acked-by: 's avatarAdrian Reber <areber@redhat.com>
      Signed-off-by: 's avatarAndrei Vagin <avagin@virtuozzo.com>
      7c0cedd8
  2. 05 Oct, 2017 2 commits
  3. 27 Sep, 2017 1 commit
    • Pavel Emelyanov's avatar
      criu: Version 3.5 · 91bc6e07
      Pavel Emelyanov authored
      So, the long-running task with lazy restore is (almost) finished :) Some
      issues are still to be resolved, but the heaviest lift has been done.
      
      Another notable thing is VDSO C/R rework. It's now more robust and fast.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      91bc6e07
  4. 25 Sep, 2017 1 commit
  5. 22 Sep, 2017 2 commits
  6. 20 Sep, 2017 29 commits