1. 01 Oct, 2014 1 commit
    • Pavel Emelyanov's avatar
      irmap: Get root mntfd before releasing tasks on predump · b4768792
      Pavel Emelyanov authored
      We have a use-after-free in predump code:
      
      1st the free_pstree() is called in pre_dump_tasks(), then we
      go to irmap_predump_run() which may call the lookup_irmap()
      which, in turn, dereferences the root_item to get the root
      mount ns fd.
      
      But the problem is bigger than that. After we've released the
      tasks (done before freeing pstree on predump) we can no longer
      access them by PIDs, so keeping the root-item after irmap
      scan is not a fix.
      
      Fix is to get the root fd before releasing the tasks and using
      one in irmap scanner.
      
      Caught recently on iterative inotify_irmap test.
      Signed-off-by: 's avatarPavel Emelyanov <xemul@parallels.com>
      Acked-by: 's avatarAndrew Vagin <avagin@parallels.com>
      b4768792
  2. 30 Sep, 2014 21 commits
  3. 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
  4. 24 Sep, 2014 2 commits
  5. 23 Sep, 2014 8 commits