1. 10 May, 2017 35 commits
  2. 24 Apr, 2017 1 commit
    • Pavel Emelyanov's avatar
      criu: Version 3.0 · fce87893
      Pavel Emelyanov authored
      So, we've done a HUUGE rework in this release, that's why it's 3.0.
      Two biggest changes are:
      
      * Compel library -- the framwork for parasite code injection.
      * 32bit x86 support. Note, that it's neither x32 support, not 32-bit
        criu. It's purely the ability to dump 32-bit tasks on 64-bit host.
      
      With compel at hands the 'criu exec' is removed.
      
      Main set of kudos go to Cyrill and Dima for this heavy lifting :)
      
      Other things include shutdown-ed UDP sockets, bind-mounts to external
      bind mounts, ASAN, extentions to RPC, rework of SysVIPC shmem dump
      format and some bugfixes and beautifications in CRIT.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      fce87893
  3. 20 Apr, 2017 3 commits
  4. 17 Apr, 2017 1 commit
    • Dmitry Safonov's avatar
      arm: Workaround shmat() page coloring alignment · e98d16e7
      Dmitry Safonov authored
      Please, see incode comment about the issue.
      There was an attempt to fix this feature in kernel:
        http://www.spinics.net/lists/arm-kernel/msg258870.html
      
      I'll send a patch for kernel with a correct justification.
      Still it's worth to workaround this on older kernels.
      mremap() after shmat() makes it possible to C/R shmem between ARMv7 CPUs.
      Without it C/R will fail even on the same platform.
      
      That is possible that this workaround changes *restore failure* to
      *corruption* in shared memory after restore.
      Still, I think it's worth to be applied by the following reasons:
      1. All ARMv7 CPUs do not have VIPT aliasing data cache.
         And ARMv6 CPUs may have any, but they are not popular because of UMP.
      2. SysV IPC shmem should be writable and SHMLBA unaligned
         (if it's only readable, then it's OK).
      3. For the data corruption we need to migrate from non-VIPT cached CPUs
         to VIPT aliasing.
      4. As this is shmem migration between platforms - quite likely we have
         it`s copy (in case of whole IPC namespace dump - in images).
      5. C/R before on the same CPU may fail (quite likely, more than 50% of
         zdtm/transition/ipc failed while I've test it).
      
      So, I think it's very unlikely that someone uses CRIU to migrate
      from ARMv7 to ARMv6 unaligned writable shmem, but if he is - here is
      a BIG WARNING on restore.
      
      And after all: we've restored application as it was on checkpoint,
      we can't reliably tell that shmem needs align on the target platform,
      but we warned on restoring.
      
      I wanted to test the cpuid for VIPT caching firstly, but it's in cp15
      coprocessor, which means it's unavailable from userspace. Only one
      reliable way to tell is to check couple of first boot lines in dmesg:
      [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
      Signed-off-by: 's avatarDmitry Safonov <dsafonov@virtuozzo.com>
      Signed-off-by: 's avatarAndrei Vagin <avagin@virtuozzo.com>
      e98d16e7