1. 06 Sep, 2016 5 commits
  2. 15 Aug, 2016 1 commit
    • Pavel Emelyanov's avatar
      criu: Version 2.5 · c0314172
      Pavel Emelyanov authored
      Bug-fix mostly release.
      
      We've also came very close in -dev branch to having x86 32bit
      support, so hopefully we'll have it in 2.6/2.7. Lazy restore
      now in test-able state, but still we want kernel patches to
      leave maintainer's tree, so we still wait.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      c0314172
  3. 11 Aug, 2016 20 commits
  4. 08 Aug, 2016 11 commits
  5. 05 Aug, 2016 1 commit
  6. 02 Aug, 2016 1 commit
    • Dmitry Safonov's avatar
      cr-exec: initialize kdat.{task_size, has_compat_sigreturn} on criu exec · da9315d8
      Dmitry Safonov authored
      For `criu exec` we are searching for a place for syscall injection.
      While searching for a VMA with PROT_EXEC and with needed size,
      we check that VMA is lower than task_size.
      The callpath for it is:
      cr_exec => parasite_prep_ctl => get_vma_by_ip
      
      Firstly, I thought to omit kdat.task_size checking if it's not inited:
      > if (vma_area->e->start >= kdat.task_size && kdat.task_size)
      but I think it's a hack then a proper solution.
      Besides, this code still can choose VMA over task_size on ARM
      and try to inject syscall there (IIRC, ARM has kernel-mapped
      VMA in that area).
      
      So, lets init kdat.task_size for `criu exec`.
      Also lets init kdat.has_compat_sigreturn so we could exec into
      compatible applications.
      
      Cc: Christopher Covington <cov@codeaurora.org>
      Cc: Andrew Vagin <avagin@virtuozzo.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: 's avatarDmitry Safonov <dsafonov@virtuozzo.com>
      Reviewed-by: 's avatarChristopher Covington <cov@codeaurora.org>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      da9315d8
  7. 01 Aug, 2016 1 commit
    • Dmitry Safonov's avatar
      build/nmk: declare build-as as a recursive · 3693c5e6
      Dmitry Safonov authored
      So, how it was working:
      1. build-as was declared with $$(1) and $$(2) which were expanded
      on entering the submake;
      2. function $(call build-as,...) performed the second expansion of
      build-as.
      
      Cons: build-as works only in sub-makefile, no sub-sub-makefile, no
      upper/top makefile.
      
      Simplify this by single $(1).
      Then build-as variable will be used _only_ in makefile, not in
      sub-makefiles.
      
      This is for now fine, as each file, that calls $(MAKE) with
      $(build)=dir or $(call build-as,makefile,dir) will include main.mk
      from NMK, which has build-as definition (from include.mk).
      
      In the future, we'll get rid of $(build) and $(build-as) workarounds
      as finally switch to building from a global makefile.
      
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: 's avatarDmitry Safonov <dsafonov@virtuozzo.com>
      Signed-off-by: 's avatarCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      3693c5e6