The statfs is not required, we now check for fd being a socket with S_IFSOCK.
The 2nd stat is just not needed, the caller provides stat info.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This structure is actualy an fd parameter, so put it there. This will also
help with future patching.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Since we're able to simply drain file descriptors
we're interested in, just do that with parasite
help.
This changes the calling sequence a bit
1) Collect file descriptors before parasite
get intected the dumpee and remember them in
local copy.
2) Ask parasite to drain collected descriptrs
into our space.
3) Operate with file descriptors directly via fcntl
calls and such.
Overall idea is to prepare ground for fowners
dumping which will be addressed in further patches.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Just implemented but not yet used in dumping procedure,
this will be addressed in further patches.
Note the space for file descriptors is statically allocated
in 8K arguments area, not on stack.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We will need these helpers to transfer file
descriptors from dumpee to our space.
Also make send_fd/recv_fd to be a wrappers over
send_fds/revc_fds to not duplicate the code.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To be able to use scm_fdset structure the two helpers
added scm_fdset_init_chunk and scm_fdset_init.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This structure will serve for multiple fds transmission/receive.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We will need them in file descriptors transfer addressed in further patches.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We will need it in parasite code where we can't use libc functions.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is not good to update images while restoring.
Thus, read vma_entry-es once into a list, put opened (when required) fds
in there and make restorer walk the entries in mem, not those read from
the image file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
These chunks of memry, which transit into restorer code gets unmapped one-by-one and thus each of them
should be page-aligned.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Now every inetsk fd dump results in a new entry in the fdinfo.img file. Sockets itself are
dumped into inetsk.img global image file. On restore the generic fdinfo redistribution algo
is used and inet sockets are opened only when required.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Each fdset item now has the callback which will show a contents of a magic-described
image file. Per-task and global show code is reworked to walk the respective fdsets
and calling ->show on each file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To be consistent. Mutexes are futex based but have
own semantics so better to be able to distinguish
the types.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrey Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Instead of open-coded u32 variables poking lets use
futex_t type and appropriate helpers where needed.
This should increase readability.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrey Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
After we removed the pid from pstree image file the -t or -p option for show
command no longer makes sense. Make 'show' mode rely on -D option to find out
where to find the root (i.e. pstree.img) file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This contains reg-files and sk-queues images, as they contain data
which is potentially generated by every task, so keep it open all
the time dump goes.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Current fdsets are ugly, limited (bitmask will exhaust in several months) and
suffer from unknown problems with fdsets reuse :(
With new approach (this set) the images management is simple. The basic function
is open_image, which gives you an fd for an image. If you want to pre-open several
images at once instead of calling open_image every single time, you can use the
new fdsets.
Images CR_FD_ descriptors should be grouped like
_CR_FD_FOO_FROM,
CR_FD_FOO_ITEM1,
CR_FD_FOO_ITEM2,
..
CR_FD_FOO_ITEMN,
_CR_FD_FOO_TO,
After this you can call cr_fd_open() specifying ranges -- _FROM and _TO macros,
it will give you an cr_fdset object. Then the fdset_fd(set, type) will give you
the descriptor of the open "set" group corresponding to the "type" type.
3 groups are introduced in this set -- tasks, ns and global.
That's it.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Write two helpers for opening an fdset for task and one for ns.
This probably can be done with some "generic" macro(s), but this
time it's simpler not to produce more code of that type.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's not required any longer. Now fdsets are allocated one-by-one only
when required and there's no need in adding new fds to existing sets.
Thus just remove the last arg from cr_fdset_open.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Move the fdset allocation inside dump_one_task and do it only for
non-zombies.
This makes sure we don't need to re-use an fdset, since we do allocate
it only when required.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This fd is global, so make it such. It will stop being just a global
variable soon.
Plus, remove the pid arg from format.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This routine is used for dumping tasks, threads and zombies. For the
last two the whole fdset is not allocated thus it will be better to
use single fd in this case.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Pid number is redundant - this file is one for the whole tree.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Since now on the fdinfo image only contains plain fdinfo_entry-es.
The tpye == FDINFO_REG files are described by regfiles.img entries
and are matched by te ID in both.
At dump stage each new ID generated results in a new entry in the
regfiles.img. At restore stage open_fe_fd should open a regfile by
the fdinfo's ID. Now this is done in suboptimal way, need to improve.
Show shows both images separately.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This will be required to determine whether we should dump the respective
file, or it was already dumped and we just re-use its id in fdinfo_entry.
For special fd-s the ID is always new.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Make fdinfo_entry carry only the minimal info describing a file
descriptor -- the fd value itself, the fd type (regular file, exe
link, cwd, filemap and it will be pipes, sockets, inotifies, etc.)
and the describing file ID.
The mentioned ID will identify the type-d object, e.g. for regfiles
this ID is already generated with file-ids.c code.
The other part of this structure describes a regfile (i.e. a file
opened with open syscall). I put this new entry at the end of the
fdinfo_entry just to make the patching simpler. Soon this entry
will be dumped into its own file.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
