One of such things we use right now is the device for anon shmem
mappings backing. In the furure this can be extended to check for
various kernel features.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
On error paths we don't explicitly close procfile.
CID 996191 (#5 of 6): Resource leak (RESOURCE_LEAK)
22. leaked_storage: Variable "f" going out of scope leaks the storage it points to.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
mnt_entry contains a few strings and they should be release too
CID 996198 (#4 of 4): Resource leak (RESOURCE_LEAK)
20. leaked_storage: Variable "pm" going out of scope leaks the storage
it points to.
CID 996190 (#1 of 1): Resource leak (RESOURCE_LEAK)
13. leaked_storage: Variable "new" going out of scope leaks the storage
it points to.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
CID 996207 (#1 of 1): Out-of-bounds access (OVERRUN)
5. alloc_strlen: Allocating insufficient memory for the terminating null of the string.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
I will have to push some sort of map of pages to dump into parasite.
For this, I need to have estimation of how much memory I'd need for
than in parasite args. These two values will help with it.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Right now when we collect list of vmas we need to know the
number of elements in it. In the future I will need to know
more, so it makes sense to create a vmas-list object for it.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
They are really depends on CPU we're running on.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Oracle has such mappings.
v2: add check, that a file is a character device
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We collect all file locks to a golbal list, so we can use them easily
in dump_one_task. For optimizaton, we only collect file locks hold by
tasks in the pstree.
Thanks to the ptrace-seize machanism, we can aviod the blocked file lock
issue, makes the work simpler.
Right now, the check handles only one situation:
-- Dumping tasks with file locks hold without the -l option.
This covers for the most part. But we still need some more work to make
it perfect robust in the future.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch replaces the format specifier %ld with PRIx64
in the following places:
* the format string argument of the functions scanf() and printf(),
* in the macros GEN_SYSCTL_*_FUNC.
We need explicit specification of the integer size there.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This removes code duplication. There is no strong
need for free_fhandle but I decided to add it to
be consistent with alloc/free handlers.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch is intended to reduce the usage of the macro P() since
integer size mismatches sometimes may be fixed by this type generalization.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
* 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>
This patch add ability to test /proc/cpuinfo data
we're interested in at the moment.
The code provides the following functionality
- cpu_init, to parse cpuinfo and check if the
host cpu we're running on is suitable enough
for FPU checkpoint/restore. If FPU present then
there must be at least fxsave capability present
- cpu_set_feature/cpu_has_feature helpers which
provides to test certain bits and set them where
needed (we need to set bits when parse cpuinfo)
Note, we reserve space for all cpuinfo bits known
by the kernel at moment, while use only three FPU
related bits for a while. This is done because we might
need to use or find out other features in future.
After all it's just 40 bytes of memory needed to keep
all possible bits.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Since fdinfo patches were merged to -mm
tree the output format has been slightly
changed. So update our tool accordingly.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Same as eventpoll -- we might have no watchee assigned
but only inotify descriptor created.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Linux kernel emulates anon-shared mappings by mapping internal
tmpfs file in. We try to detect this by checking that the file
under map is such, but do it with error -- major == 0 check is
wrong, as regular tmpfs file can be such as well as btrfs or
ecryptfs can screw things up.
The only working way of doing this is to get the dev_t of this
internal tmpfs mount.
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 kernel now supports providing VMA flags via smaps
interface so add pasting of them.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Before 256 bytes were used for that, it may be not enough.
For example it was not enough for a NFS point on my test system.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is normal situation -- eventpoll fd may have no fds attached
thus resulting in empty fdinfo file. Report OK in that case.
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>
We need to dump content of some fs like binfmt_misc, tmpfs, ... To facilitate
this the existing list of filesystems is turned into an array of structures
with dump and restore callbacks. Each FS may declare them they need.
v2: rework encode/decode_fstype not to do it twice.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This types specifies a strict set of what is hidden behind
the fd. Thus these numbers should be in the description of
the fdinfo message.
Plus protobuf makes shure nothing else will be there.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Build a tree of mountpoins that can be (u)mounted in a straight
(forward or backward) order without EBUSY errors.
The tree is built in two steps -- first create hierarchy based
on mount iDs. Next -- resort siblings in the path depth order.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This structure will be used on restore and will be created
from the image, thus the name proc_ is not suitable.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
On the restore path this structure will be used and it
will be better to have them char * rather than char[64].
When scanning proc use the %ms specifier for this.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The task is not complete - this is just a part of what have to be done. I.e.
looks like a lot of excessive deps can be fixed.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The proc_parse file turns into a strange pile of homebrew
scanf/fgets/strtok/strchr/etc. combination. I don't like it :(
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We'll have to parse it all and the format is not scanf
friendly, so it's simpler to have it in a separate fn.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Make the proc_mountinfo obtaned after parse form a single linked list.
That's much easier to handle and doesn't have an artificial limitation
of 64 items...
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
What is stored there is the path to mountpoint. The root
is the field previously named "parent root".
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To restore inotify we need to know the
mount point device numbers, so this helper
parses /proc/pid/mountinfo file for that.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
