zdtm: Add ability just to start the test

When running test with ns/ prefix zdth.sh does complex preparations.
Make it possible to make them and let started process ready for
manual investigation.

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
util: Prepare proc opening helpers to open any files

We have a set of routines that open /proc/$pid files via proc service
descriptor. Teach them to accept non-pids as pids to open /proc/self/*
and /proc/* files via the same engine.

Signed-f-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
restore: Open /proc/self/maps via helpers

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
restore: Open /proc/sys/kernel/ns_last_pid via helpers

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
restore: Do fchroot() via proc helpers

There's no such thing as fchroot() in Linux, but we need to do
chroot() into existing file descriptor. Before this patch we did
this by chroot()-ing into /proc/self/fd/$fd. W/o proc mounted it's
no longer possible, so do this like

fchdir(proc_service_fd);
chroot("./self/fd/$root_fd");
fchdir($cwd_fd);

Thanks to Andrey Vagin for this trick ;)

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
zdtm: Add test for mount namespace w/o mountpoints

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
vdso: image -- Add VMA_AREA_VVAR flag

Will need it to handle vvar zones in a special way.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
vdso: dump -- Don't dump contents of vvar zone

vvar zone is mapped by a kernel and must not ever
been dumped into image, the data present there is
valid on running kernel only.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
vdso: util -- Show 'vvar' abreviature when meet VMA_AREA_VVAR

This is for debug purpose mostly.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
vdso: parasite -- Prepare new vdso mark structure.

Because of new vvar area we need to carry the
address of vvar proxy inside the mark. Thus
add members needed and update routines.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
vdso: x86 -- Add handling of vvar zones

New kernel 3.16 will have old vDSO zone splitted into the two vmas:
one for vdso code itself and second that named vvar for data been
referenced from vdso code.

Because I can't do 'dump' and 'restore' parts of the code separately
(otherwise test would fail) the commit is pretty big one and hard to
read so here is detailed explanation what's going on.

 1) When start dumping we detect vvar zone by reading /proc/pid/smap
    and looking up for "[vvar]" token. Note the vvar zone is mapped
    by a kernel with PF/IO flags so we should not fail here.

    Also it's assumed that at least for now kernel won't be changed
    much and [vvar] zone always follows the [vdso] zone, otherwise
    criu will print error.

 2) In previous commits we disabled dumping vvar area contents so
    the restorer code never try to read vvar data but still we need
    to map vvar zone thus vma entry remains in image.

 3) As with previous vdso format we might have 2 cases

    a) Dump and restore is happening on same kernel
    b) Dump and restore are done on different kernels

    To detect which case we have we parse vdso data from image
    and find symbols offsets then compare their values with runtime
    symbols provided us by a kernel. If they match and (!!!) the
    size of vvar zone is the same -- we simply remap both zones
    from runtime kernel into the positions dumpee had at checkpoint
    time. This is that named "inplace" remap (a).

    If this happens the vdso_proxify() routine drops VMA_AREA_REGULAR
    from vvar area provided by a caller code and restorer won't try
    to handle this vma. It looks somehow strange and probably should
    be reworked but for now I left it as is to minimize the patch.

    In case of (b) we need to generate a proxy. We do that in same
    way as we were before just include vvar zone into proxy and save
    vvar proxy address inside vdso mark injected into vdso area. Thus
    on subsequent checkpoint we can detect proxy vvar zone and rip
    it off the list of vmas to handle.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>