It doesn't make sense to try to connect sockets if error
happened previously.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It's confusing to see the output like

 | Got fd for 3
 | Got fd for 3

Better to point what is going on

 | Got fd for 3 (state -> 0)
 | Got fd for 3 (state -> 1)
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

No need to obtain MAGIC_OFFSET from current position,
the files have predefined structure.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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

This bit is not per-file, but per-fd, thus put it on the fdinfo_entry.
Draing these bits from parasite together with the fds themselves, save
into image and restore with fcntl F_SETFD cmd where applicable.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The flags are only one bit in the kernel (close-on-exec, all the rest are not per-fd, but per-file),
but for simplicity I save it in a char field.
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 is required for proper close-on-exec handling (coming soon) and for fowners (coming soon
as well) and for file flags (yes, yes).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It used to be ulong, but it can be int now (no mapping addresses there). And the
name fd is better than fd_name (reason is the same).
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>

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

reopen_fd_as closes old descriptor.
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>

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

Just dump their IDs and check they are not shared. For future.
IO and SEMUNDO is not there since tasks may have NO such objects
and currently we cannot detect whether they have them equal or
both don't have.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Just move the patched code from file-ids.c to kcmp-ids.c and
make the former one be client for the latter.
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>

2nd step in making kid tree generic.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

kid_ stands for kernel id and this is preparation for making the fd_id_
tree generic enough to support any type of kcmp- calls.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Now we store only real fdtable entries in this file, so it's
time to name the field properly and change type to u32.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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

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

It's no longer required. All the previously special fds are
now scattered over other images.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This is mm_struct entity, so save one there. Also gets rid
of special FDINFO-s.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The mm_xxx bits are per-mm_struct, not per-task_struct in kernel.
Thus, when we support CLONE_VM we'd better have these bits in a
separate image file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Do not restore it yet -- the logic we're about to apply to
resolve tasks' paths relative to dumper/restorer is not yet
clear to me and it should better be hidden into a couple of
calls (dump_one_reg_file/open_fe_fd). But since we can't
chroot to fd we're about to expose the logic outside of the
open_fe_fd, which is not desirable ATM.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Why? Because one day we'll support various CLONE_ flags and
for fdtable and fs info we'd like to have separate images (since
these objects are separate in kernel).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The regfile's ID of a VMA is stored in its shmid field. And the
file itself if sumped into regfiles.img image with 'special'-ly
generated ID (i.e. -- just allocate a new unique one).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

It's an O(n) algorithm.

Now we iterate both lists simultaneously to find a hole.

[xemul: Discussion making the patch more understandable:

Cyrill:

	If s_vma is the last one on self_vma_list you could break immediately, no?

	And the snippet I somehow miss is -- how the situation handled when

		      hole
		    a      b
	source |----|      |-----|
	target   |----|      |-----|
		      c      d

	the hole fits the requested size but the hole is shifted
	in target, so that you've

	prev_vma_end = a

	and then you find that a - d > vma_len and return a
	as start address for new mapping while finally it
	might intersect with address c.

	Or I miss something obvious?

Andrey:

	Look at "continue" one more time.
	prev_vma_end is returned only if both condition are true

	if (prev_vma_end + vma_len > s_vma->vma.start) {
	....
	if (prev_vma_end + vma_len > t_vma->vma.start) {
	...
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Looks-good-to: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Because amount of entries are known.
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>

[ xemul: The fix effectively is -- stop scanning the 2nd vma list
         once we see, that the hint's end hits the next vma ]
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

A file pointed by an fd should be not unlinked
and be open-able with the provided path (overmounts
and/or renames coupled with links can screw it up).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

In case if no goals specified the all
goal is implied so don't forget to generate
deps. This as well fixes a problem where
two "make clean" in a row forced build system
to regenerate deps.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Looks-good-to: Stanislav Kinsbursky <skinsbursky@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>