bfd: move the optimization in a proper place

Currently this optimization skips unscanned data
and doesn't work. Lets skip scanned data only.

Reported-by: Jenkins
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
mntns: don't dump criu's namespace

Reported-by: Mr Jenkins
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
vma: Reshuffle the struct vma_area

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: Pavel Emelyanov <xemul@parallels.com>
vma: Add comments about some dump fields of vma_area

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: Pavel Emelyanov <xemul@parallels.com>
filemap: Get vma mnt_id early

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: Pavel Emelyanov <xemul@parallels.com>
proc: Sanitate empty lines

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
fd: Close caches proc-pid stuff before restoring files

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: Pavel Emelyanov <xemul@parallels.com>
proc: Keep /proc/self cached separately from /proc/pid

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: Pavel Emelyanov <xemul@parallels.com>
dump: Don't close pid-proc in vain

The open_pid_proc engine knows itself how to cache
per-pid descriptors. No need in closing it by hands.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
bfd: Multiple buffers management (v2)

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: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
zdtm/cwd01: don't forget to set '\0' after readlink()

Cc: Konstantin Neumoin <kneumoin@parallels.com>

Reported-by: OpenVZ QA
zdtm/tempfs: set mode for O_CREAT

man 2 open:
"""
mode specifies the permissions to use in case a new file is cre‐
ated.  This argument must be supplied when O_CREAT or O_TMPFILE
is specified in flags;
"""

Cc: Konstantin Neumoin <kneumoin@parallels.com>
mount: rework perparation for pivot_root (v2)

We can't bind-mount the required root into itself instead of
resolving a parent mount.

This patch is required to support userns, because if we want to make
pivot_root, the parent mount can't be locked. When we create userns
and mntns, all inherited mounts are marked as locked.

v2: don't change properties of the given root

Cc: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
[RFC] perf: Here is an example how to trace syscalls

perf doesn't affect performance so significant as strace and
it allows to trace parasite code.

All processes are executed in a new perf_evets cgroup and
"perf record" collects events only for processes from this group.
Revert "[RFC] perf: Here is an example how to trace syscalls"

This reverts commit e97f84cc8097e9ce07c216f2b3507111a32ce71f.
criu: add .travis.yml (v2)

"""
Travis CI is configured by adding a file named .travis.yml, which is a
YAML format text file, to the root directory of the GitHub
repository.[5]

Travis CI automatically detects when a commit has been made and pushed
to a GitHub repository that is using Travis CI, and each time this
happens, it will try to build the project and run tests.
""" https://en.wikipedia.org/wiki/Travis_CI

Currently Travis CI builds criu for x86_64 and ARM

v2: move travis-ci.sh in scripts