Completely unlinked file is the one with n_link count being zero.
Such files only allow to read their contents and carry with us.

In order to dump this thing I introduce the "path remap" technology.
For reg file a remapping entry is dumped which describes, that at
restore stage before opening a regfile->path this path should be
linked to some other name and then (after open) unlinked.

For completely unlinked files the remap path would be a path to
a "ghost" file, i.e. a file which is created only at the time of
restore and which is removed completely at the end of it.

Partially unlinked files (i.e. those having n_link != 0, but a
path by which we see them in someone's fd is not accessible) should
be handled in another way.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Will be required to dump completely unlinked files.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This is trivial. Just copy-n-paste pieces from the udp dumping
and restoring code. The zdtm test is also a compy of the _udp
test with respecitve changes.

Reuired for httpd, this one uses udplite sockets.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

In case if unix socket was not found don't call for container_of.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Most likely they left from Andrey's shmem rework.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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

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

Otherwise output looks like

Dumping core (pid: 16953)
----------------------------------------
Dumping GP/FPU registers ... OK
Obtainting personality ... OK
Obtainting task auvx ... Dumping path for 1 fd via self 19 [/home/crtools/test/legacy/test-inotify]
Dumping header ... ----------------------------------------

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

Generate a pseudorandom tree of files, run tar cjf on it
to create referenced tarball, then run the same again on
the background, wait for a while, then checkpoint and restore
it and compare that two tarballs do not differ.
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: 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>

The intention is to put here tests, that check how real apps
work. Initially I test that make -j4 works. This test is very
basic (uses sleep to wait for make to fork everybody) and a
syntetic .c file (quite big though).

Extend and use.
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: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Tests for pipes fowners checkpoint/restore.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

The base idea is trivial, once file descriptor
created the owner is read and set up.
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>

Just show implemented and stubs added to image
(regular file and pipes).
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>

If I'm not mistaken this covers all the if-s in the
restore_pgid and restore_sid code.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This is preriquisity for terminals handling and just a good
practice to save and restore everything we can :)

Not all combinations are supported. All the problems we still
have come from the inability to attach to group/session with
ID no tasks own as its PID.

This can be workarounded by fork()-ing this pid temporarily,
but we'd rather think in the direction of modifying the kernel
to give us direct syscall for this (oh my...)
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

I store them on _entry since sids can only be inherited or
set to current's pid. Thus the best we can do it restore sids
at fork time, thus save them in the image we use to fork.

Maybe when we submit patches that will give us ability to set
arbitrary pgid and sid we'll change this, but this is in the
future.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

They are just two next in this file, so extend. This is
required for pgid/sid early read, see next patches for
details.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This is trivial change, but is required to check for pgid/sid
are in 'restorable' state, see for respective patch/code for
details.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

New stage CR_STATE_FORKING. This is required to restore pgids
properly -- we need to make sure a task with pid whose pgid we
are about to enter is alive. And this task is not necesserily
our parent, thus wait for everyone to appear.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Otherwise multiple writers can screw each-other's messages.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

Wile the task is infected we cannot just detach from it and go away. The victim will die after this.
So, call the parasite_cure_seized on any error handing between infect and cure.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

This is not very good practice :) Just leave them in the state they've been to before
dumping. Plz note, that tasks segfault for some reason after unseizeing, but this is
another story.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

For regfiles this is done at open() time, for pipes thit is done with fcntl. Use
the same fcntl approach for sockets.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

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>