1. 30 Sep, 2014 11 commits
  2. 29 Sep, 2014 8 commits
    • Pavel Emelyanov's avatar
      bfd: Multiple buffers management (v2) · 5eb39aad
      Pavel Emelyanov authored
      I plan to re-use the bfd engine for images buffering. Right
      now this engine uses one buffer that gets reused by all
      bfdopen()-s. This works for current usage (one-by-pne proc
      files access), but for images we'll need more buffers.
      
      So this patch just puts buffers in a list and organizes a
      stupid R-R with refill on it.
      
      v2:
        Check for buffer allocation errors
        Print buffer mem pointer in debug
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      Acked-by: 's avatarAndrew Vagin <avagin@parallels.com>
      5eb39aad
    • Pavel Emelyanov's avatar
      dump: Don't close pid-proc in vain · 1a2e6cbd
      Pavel Emelyanov authored
      The open_pid_proc engine knows itself how to cache
      per-pid descriptors. No need in closing it by hands.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      1a2e6cbd
    • Pavel Emelyanov's avatar
      proc: Keep /proc/self cached separately from /proc/pid · abeae267
      Pavel Emelyanov authored
      When dumping tasks we do a lot of open_proc()-s and to
      speed this up the /proc/pid directory is opened first
      and the fd is kept cached. So next open_proc()-s do just
      openat(cached_fd, name).
      
      The thing is that we sometimes call open_proc(PROC_SELF)
      in between and proc helpers cache the /proc/self too. As
      the result we have a bunch of
      
        open(/proc/pid)
        close()
        open(/proc/self)
        close()
      
      see-saw-s in the middle of dumping tasks.
      
      To fix this we may cache the /proc/self separately from
      the /proc/pid descriptor. This eliminates quite a lot
      of pointless open-s and close-s.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      abeae267
    • Pavel Emelyanov's avatar
      fd: Close caches proc-pid stuff before restoring files · 829d4332
      Pavel Emelyanov authored
      We have a bug. If someone opens proc with open_pid_proc or alike
      with PROC_SELF of real PID before going to restore fds, then the
      fd cached by proc helpers would be cached in fd 0 (we close all
      fds beforehead) and it may clash with restored fds.
      
      We don't hit this right now simply due to being too lucky -- we
      call open_proc(PROC_GEN) on "locks" which first closes the cached
      the per-pid descriptor and then reports back just the /proc one
      which sits in service area.
      
      But once we change this (next patch) things would get broken.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      829d4332
    • Pavel Emelyanov's avatar
      proc: Sanitate empty lines · 1c8ab40e
      Pavel Emelyanov authored
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      1c8ab40e
    • Pavel Emelyanov's avatar
      filemap: Get vma mnt_id early · e651a6eb
      Pavel Emelyanov authored
      We have a, well, issue with how we calculate the vma's mnt_id.
      
      Right now get one via criu side file descriptor that it got by
      opening the /proc/pid/map_files/ link. The problem is that these
      descriptors are 'merged' or 'borrowed' by adjacent vmas from
      previous ones. Thus, getting the mnt_id value for each of them
      makes no sense -- these files are the same.
      
      So move this mnt_id getting earlier into vma parsing code. This
      brings a potential problem -- if we have two adjacent vmas
      mapping the same inode (dev:ino pair) but living in different
      mount namespaces -- this check would produce wrong result.
      "Wrong" from the perspective that on restore correct file would
      be opened from wrong namespace.
      
      I propose to live with it, since this is not worse than the
      --evasive-devices option, it's _very_ unlikely, but saves a lot
      of openeings.
      
      Note, that in case app switched mount namespace and then mapped
      some new library (with dlopen) things would work correctly -- new
      vmas will likely be not adjacent and for different dev:ino.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      e651a6eb
    • Pavel Emelyanov's avatar
      vma: Add comments about some dump fields of vma_area · f84d19e0
      Pavel Emelyanov authored
      We have non-obvious handling of vm_file_fd/vm_socket_id
      pair and the vma->file_borrowed.
      
      Comment these to in the structure.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      f84d19e0
    • Pavel Emelyanov's avatar
      vma: Reshuffle the struct vma_area · cf8c9ae8
      Pavel Emelyanov authored
      We have some fields, that are dump-only and some that
      are restore only (quite a lot of them actually).
      
      Reshuffle them on the vma_area to explicitly show which
      one is which. And rename some of them for easier grep.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      cf8c9ae8
  3. 24 Sep, 2014 2 commits
  4. 23 Sep, 2014 10 commits
  5. 22 Sep, 2014 7 commits
  6. 19 Sep, 2014 2 commits
    • Andrey Vagin's avatar
      restore: use breakpoints instead of tracing syscalls · 248fc315
      Andrey Vagin authored
      Currently CRIU traces syscalls to catch a moment, when sigreturn() is
      called. Now we trace recv(cmd), close(logfd), close(cmdfd), sigreturn().
      
      We can reduce a number of steps by using hw breakpoints. A breakpoint is
      set before sigreturn, so we will need to trace only it.
      Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      248fc315
    • Andrey Vagin's avatar
      dump: use breakpoints instead of tracing syscalls (v2) · 0b1b8151
      Andrey Vagin authored
      Currently CRIU traces syscalls to catch a moment, when sigreturn() is
      called. Now we trace recv(cmd), close(logfd), close(cmdfd), sigreturn().
      
      We can reduce a number of steps by using hw breakpoints. A breakpoint is
      set before sigreturn, so we will need to trace only it.
      
      v2: In the first version a breakpoint is set after sigreturn. In this
      case we have a problem with signals. If a process has pending signals,
      it will start to precess them after exiting from sigreturn(), but before
      returning to userspace. So the breakpoint will not be triggered.
      
      And at the end Here are a few numbers how we catch sigreturn.
      Before this patch criu executes 36 syscalls and gets 12 signals.
      With this patch criu executes 18 syscalls and gets 5 signals.
      Signed-off-by: 's avatarAndrey Vagin <avagin@openvz.org>
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      0b1b8151