* The following files goes into the directory arch/x86/include/asm unmodified:
- include/atomic.h,
- include/linkage.h,
- include/memcpy_64.h,
- include/types.h,
- include/bitops.h,
- pie/parasite-head-x86-64.S,
- include/processor-flags.h,
- include/syscall-x86-64.def.
* Changed include directives in the source files that include the headers
listed above.
* Modified build scripts to reflect the source moves.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The dumping of FPU state is done with help of ptrace
facility. There are two cases which we need to handle
depending on which features are available on host machine
1) The dump via ptrace(PTRACE_GETFPREGS ...)
In this case the kernel will use fxsave approach
inside the kenrel and provides us back the data
encoded in i387_fxsave_struct format.
2) The dump via ptrace(PTRACE_GETREGSET ...)
In this case the kernel will use xsave approach
inside the kernel and provides us back the data
encoded in xsave_struct format.
In any case we decode data and save it in protobuf format.
This is why core.proto file has been extended to keep new
entries.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
And don't forget to undef them once they are not needed.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Actually it was never used, just drop it.
Because of backward compatibility problem we
can't just zap it in protofile.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The cpu we're running on must at least support fxsave feature.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
I've moved dump_thread helper a bit lower in file
since I've to call for find_thread_state helper.
After all this groups all thread related functions
in one slab.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch starts using parasite_init_threads_seized and
parasite_fini_threads_seized helpers to save per-thread
data in parasite and remove it on cure procedure.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The per-thread information requires own space in parasite data.
In particular we will keep the blocked signals bound to thread
pids.
For this sake the caller need to provide the parasite how many
threads will be used to calculate space.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Three parts.
Proc: open of map_files' link doesn't work on sockets. We fstatat
it and check that it's a socket (it will be packet), then save
the socket inode on vma_area.
Dump: we resolve socket inode to socket id and save it on vma.
We use id, not inode, since on restore we'll have to mmap some
opened file, not just abstract socket with inode.
Restore: when reading vma-s we just need to find out on what fd
the respective packet socket is opened (i.e. -- no map-and-close
sockets supported by now) and dup() it to let restorer mmap it
back.
All this make it possible to c/r the tcpdump tool!
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The size of vector depends on the kernel config
so use the real size of a vector dumped. Otherwise
we might fail on restore.
Reported-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The dumping of tty peers is somewhat tricky. And it became more
complex once we allowed to migrate/inherit sessions.
It's being found (in screen c/r) that we've a problem in looking
up of session leaders while dumping tty.
Let me explain with more details. Here is an example of screen
session
PID GID SID
20567 20567 20567 SCREEN
20568 20568 20568 pts/3 \_ /bin/bash
The screen opens master peer (ptmx) and then provides
bash the slave peer (pts/3) where bash sets up a session
leader on it.
Thus we get interesting scenario -- our pstree construction
is done in lazy fashion, we run parasite code to fetch sid/pgid
of a process tree item only when we're really dumping the task.
Thus when we start dumping ptmx peer (which belongs to SCREEN)
we've not yet constructed the process tree item for children
(ie /bin/bash) and the lookup function in tty code (which walks
over all process items in a tree) simply fails to find sid of
child, because we've not yet dumped it.
Thus, to resolve such situation we verify tty sids at late stage
of dumping.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
No magic here, just fetch info using getpriority and sched_getxxx calls.
Good news is that the mentioned syscalls take pid as argument and do work
with it, i.e. -- no need in parasite help here.
Restore is splitted into prep -- copy sched bits from image on restorer
args -- and the restore itself. It's done to avoid restoring tasks info
with IDLE priority ;) To make restorer not-fail sched bits are validated
for sanity on prep stage.
Minimal sanity test is also there.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Some file-type specific parameters can be fetched with
parasite code only, so lets carry parasite control block
pointer in struct fd_parms.
This is a bit ugly but requires less code to touch and
enough for now. In long terms we need some more generalized
routine/hooks which would depends on file type.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently move there the secbits dumping, which is not dumped
via misc-dumping command. This patch is required to support
per-task groups dumping (setgroups/getgroups) -- we'll have to
drain the groups from parasite.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We don't support yet detached terminals migration,
so fail early if we can't proceed.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Usually the PTYs represent a pair of links -- master peer and slave
peer. Master peer must be opened before slave. Internally, when kernel
creates master peer it also generates a slave interface in a form of
/dev/pts/N, where N is that named pty "index". Master/slave connection
unambiguously identified by this index.
Still, one master can carry multiple slaves -- for example a user opens
one master via /dev/ptmx and appropriate /dev/pts/N in sequence.
The result will be the following
master
`- slave 1
`- slave 2
both slave will have same master index but different file descriptors.
Still inside the kernel pty parameters are same for both slaves. Thus
only one slave parameters should be restored, there is no need to carry
all parameters for every slave peer we've found.
Not yet addressed problems:
- At moment of restore the master peer might be already closed for
any reason so to resolve such problem we need to open a fake master
peer with proper index and hook a slave on it, then we close
master peer.
- Need to figure out how to deal with ttys which have some
data in buffers not yet flushed, at moment this data will
be simply lost during c/r
- Need to restore control terminals
- Need to fetch tty flags such as exclusive/packet-mode,
this can't be done without kernel patching
[ avagin@:
- ideas on contol terminals restore
- overall code redesign and simplification
]
v4:
- drop redundant pid from dump_chrdev
- make sure optional fown is passed on regular ptys
- add a comments about zeroifying termios
- get rid of redundant empty line in files.c
v5 (by avagin@):
- complete rework of tty image format, now we have
two files -- tty.img and tty-info.img. The idea
behind to reduce data being stored.
v6 (by xemul@):
- packet mode should be set to true in image,
until properly fetched from the kernel
- verify image data on retrieval
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The problem is to get a virtual pid for zombies.
This code gets two list of children from current and target pidns.
Then it removes alive task from the second list and dumps remaining zombies.
A procfs from a target pidns is needed for dumping zombies,
crtools gets it from parasite code.
v2: Fix comment and get proc fd from a root task
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This proc will be used for dumping zombies from pidns.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Here is a bit mess, because we used unsigned int instead of pid_t.
A negative value is used for uninitialized PID's variables.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
pstree_item contains virtual and real pid and we want to
get children by both of this pids.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
/proc/PID/maps can contains not up to date information about a stack vma.
A kernel marks a VMA as stack, if thread_struct->usersp is in it,
but usersp is updated, when a process calls a syscall.
This problem is occured, when we try to dump/restore a process in a loop.
When a restorer resumes a process, a restorer vma will be marked as stack.
A thread stack should not be marked as stack, because its vma is mapped
w/o MAP_GROWSDOWN.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It looks better and the next patches adds more checks
before memory allocations.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
A task may be in another pidns and crtools should get a pid from this pidns.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
* Don't dumplicate array when sending to parasite
* Allocate necessary space in cr-dump for local fds/flags
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
These are used by single process, no need in keeping them in
such a strange way. Plus, turn this array into a hash table
for better search.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If netns is dumped, crtools fails if it collects unsupported sockets.
If netns isn't dumped, crtools will fail only
if an unsupported socket should be dumped.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It doesn't makemuch sense in pulling this further. The generic genid generation seems to
be enough for eny file type.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
All sockets should be collected in a target net name-space when the -n net
is specified.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch introduces ThreadCoreEntry protobuf structure which is to carry
thread-specific arch-independent information.
Now put there the c/r futex robust lists.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Only the fact of the fd presence, its flags and fown and the sigmask.
The sigpending state is tightly coupled with the task's sigpending
state which is not yet supported.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We'll need to check whether the socket is to be created in a net
namespace (since we can't detect this automatically yet). Thus the
namespaces flags are required there.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If we dump tasks with mntns, we should look at pathes from point of a mntns root.
Now we support a situation when a root of an init task has the same root as the
mntns root, because we have not another way to get a root of mntns.
A path to an unix socket is copied, because the origin copy will be gone
out from the function, where it was created.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This requires some exlanations
- Since we use protobuf data in restorer
code we need to carry a copy of appropriate
PB entities in resident memory. For this
sake task_restore_core_args and thread_restore_args
were significantly reworked. In short -- the caller
code fills PB structures into task arguments space.
v3:
- Combine everything arch related to thread_info field,
and make it optional
- Drop "version" field from message, we check version in
another specific message
- Don't forget to call core_entry__free_unpacked where needed
- We continue dumping FPU state, still it's not yet restored
v4:
- Don't carry task_core_entry and task_kobs_ids_entry for
threads, and yield error if present in image.
v5:
- Allocate core_entry depending on type of task being dumped
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We haven't tested it for several monthes and there's no evidence
it is required at all. For dumping a single task -t option works
just fine.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
