1. 07 Oct, 2015 6 commits
    • Kir Kolyshkin's avatar
      read_ns_sys_file(): don't overrun buf · ec863205
      Kir Kolyshkin authored
      This is a classical off-by-one error. If sizeof(buf) is 512,
      the last element is buf[511] but not buf[512].
      
      Note that if read() returns 0, we return 0 but buf stays
      uninitialized.
      
      Reported by Coverity, CID 114623.
      Signed-off-by: 's avatarKir Kolyshkin <kir@openvz.org>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      ec863205
    • Kir Kolyshkin's avatar
      read_fd_link(): don't overrun buf · 377763e5
      Kir Kolyshkin authored
      This is a classical off-by-one error. If sizeof(buf) is 512,
      the last element is buf[511] but not buf[512].
      
      Reported by Coverity, CID 114624, 114622 etc.
      Signed-off-by: 's avatarKir Kolyshkin <kir@openvz.org>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      377763e5
    • Laurent Dufour's avatar
      ppc64: handle gcc memcpy optimisation · 0570dd81
      Laurent Dufour authored
      The commit 871da9a1 ("pie: Give VDSO symbol table local scope")
      move the definition of the vdso_symbols from global to local variable
      in vdso_fill_symtable(). This makes sense since this variable is only
      used in this function. However this raises a build issue on powerPC,
      where a memcpy undefined symbol is detected when doing the first
      relocation phase of the parasite code:
      
      parasite_blob: Error (pie/piegen/elf.c:258): Unexpected undefined
      symbol:memcpy
      
      This memcpy symbol is pulled by the C compiler generated code which
      tries to optimize the stack initialization when entering
      vdso_fill_symtable(). The optimization is done by copying the
      initialized data to the stack using memcpy. But when building the
      parasite code, the C library is not linked and there is no memcpy
      symbol. However there is builtin_memcpy() which is doing the same.
      
      Ideally, the builtin_memcpy should be named memcpy() to replace the C
      library one, and it should only be built for the parasite/restorer
      code. But the way CRIU is built, the same vdso-util.o file is used
      twice for criu which is linked with the C library and by the
      parasite/restorer code. Thus naming builtin_memcpy memcpy leads to
      belongs on builtin_memcpy even when the C library is in the picture,
      which is not the best option (assuming C library mem operation are
      more efficient).
      
      Among the memcpy symbol issue, this shows that same objects are used
      both in CRIU and the parasite/restorer code. This should not be the
      case since parasite/restorer are built in pie form and criu's object
      not. The shared code should be built twice, once on pie form for the
      parasite/restorer code, once *normally* for the criu binary.
      
      Addressing the build issue implies more work than expected.
      For the moment, this patch is defining a memcpy service when building
      the parasite code to fix the build issue on ppc64.
      Once the build issue is addressed, builtin_memcpy should be renamed
      memcpy and only be used for parasite/restorer code, and this
      definition removed.
      Signed-off-by: 's avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      0570dd81
    • Pavel Emelyanov's avatar
      zdtm: Move towards the new generation of criu testing (v3) · 6b83934e
      Pavel Emelyanov authored
      A little bit more stuff added :) With these changes I can run the
      
        zdtm.py run --all -x cgroup -x maps04 -x different_creds -x rtc
      
      To run cgroups tests need to add .hook calls, for maps04 I don't have
      enough RAM and disk in my VM (will fix), for different_creds need to
      support crfail test option (dump _must_ fail), for rtc -- plugins.
      
      So changes since v2:
      
      1. Added exclusion (-x option)
      2. Bugfix in parallel run
      3. Fixed NS root permissions
      4. Fixed checks for maps before and after dump
      5. Fixed thread_bomb launch
      6. Print test output
      7. Support .checkskip scripts
      8. Support features
      9. Fixed test list
      
      Andrey, thoughts?
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      Acked-by: 's avatarAndrew Vagin <avagin@openvz.org>
      6b83934e
    • Andrey Vagin's avatar
    • Andrey Vagin's avatar
      mount: use absolute paths for pivot_root · e23299b4
      Andrey Vagin authored
      When we initialize a sub-mount namespace, we need to use absolute paths.
      For example we change cwd in prep_unix_sk_cwd()
      Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      e23299b4
  2. 05 Oct, 2015 11 commits
  3. 30 Sep, 2015 3 commits
  4. 28 Sep, 2015 18 commits
  5. 25 Sep, 2015 2 commits