Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

These contain linkage between number, data type and routines
for pb messages we write/read to/from image files. Most of them
have simple number-type-routines mapping, so introduce a generating
script for that.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

There's some strange setup on Jenkins boxes, so that /dev/net/tun
is inaccessible. Need to check this after holidays :(
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This thing is pretty straightforward -- on netns creation
populate it with tun-s, after this collect tun files, open
and attach them with regular fd-s engine.

One tricky thing -- when populating namespace with tun links
make them all persistent and drop this flag (if required)
later, when the first alive opened appears.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The major issue with dump is -- some info id get via netlink,
some via sysfs and some (!) via opened and attached tun file.
But the latter cannot be created, if there's another one attached
(or the mq device is full with threads).

Thus we have to dump this info via existing tun file and keep one
in memory till the link dump code takes place.

Opposite situation is also possible -- we can have a persistent
unattached device. In this case we have to attach to it, dump
things and detach back.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

There will be two entities handled:

1. tun file -- an opened char device with misc major and tun minor
   that can be attached to item #2

2. tun netdevice -- another type of links
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

TUN devices are created with ioctl, but their parameters (e.g.
flags with state, mtu, etc.) are to be restored with generic
RTM_SETLINK message.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It's not quite clean, but on dump non-seekable files dump 0xff...ff into
64-bit pos field of the image. Thus on restore we'd face an error in the
do_open_reg. In order not to have separate helper for non-seekable files
just skip the position restore for such.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Just a small helper, that reads string from ns' sysfs mount.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Some information about network devices may hide in sysfs, thus
it's required to have one at hands while dumping the netns.

Create the detached mount for that.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Some (most) network devices would like to have NetDeviceEntry with
more fields, than currently present (and enough for lo and veth).
Prepare for that by allowing them to define their own callback that
would fill the resor of the pb entry and call write_netdev_img().
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The option can run test with specified name directly without check
or match.

It can be used to run experimental test that is not in TEST_LIST.
Signed-off-by: Yicheng Qin <yichengq@google.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Now we have a set of cinfo-s, it's possible to collect all
this stuff in a plan for-loop.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

If processes are restored without pidns, criu knows pidtheir -s from images,
but part of those task may have not yet forked, and thus the pids can not
exist or (!) be used by other processes.

To address that we abort stages RESTORE_NS and FORKING without killing tasks,
but with task_entries->start futex by writing STATE_FAIL into it and making
the tasks to check that. Since during RESTORE_NS and FORKING stages tasks can
only block on the mentioned futes, we can safely do it.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Reported-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Currently, env.sh only contains the location of criu executable.
Signed-off-by: Yicheng Qin <yichengq@google.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Yicheng Qin <yichengq@google.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

To switch to kernel's style.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Use same code as provided in kernel. In first place
we used own prototypes in case of simplicity (they
all were based on "lock xadd" instruction. There is
no more need for that and we can switch to well known
kernel's api.

Because kernel uses plain int type to carry atomic
counters I had to add explicit u32 type for futexes,
as well as a couple of fixes for new api usage.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Just like kernel does.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Will need it for atomic data conversion.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Yet again -- namespaces are auto-detected now, no need in this.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

We have automatic namespaces detection, no need in this.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This thing was introduced by 01f8f8f4 to help not mixing
per-thread error messages in log files. Now messages are
not mixed by other means, so this thing is useless.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Doing it several steps further is less clean.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Currentl it waits for previous stage to complete and starts the
next one. Now it starts the next one and waits for it to complete.
The latter way fits better into both -- the code and the head.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Signed-off-by: Pavel Emelyanov <xemul@parallels.com>