During the dump phase, /proc/cgroups is parsed to find co-mounted cgroups.
Then, for each task /proc/self/cgroup is parsed for the cgroups that it is a
member of, and that cgroup is traversed to find any child cgroups which may
also need restoring. Any cgroups not currently mounted will be temporarily
mounted and traversed. All of this information is persisted along with the
original cg_sets, which indicate which cgroups a task is a member of.
On restore, an initial phase creates all the cgroups which were saved. Tasks
are then restored into these cgroups via cg_sets as usual.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
New kernel 3.16 will have old vDSO zone splitted into the two vmas:
one for vdso code itself and second that named vvar for data been
referenced from vdso code.
Because I can't do 'dump' and 'restore' parts of the code separately
(otherwise test would fail) the commit is pretty big one and hard to
read so here is detailed explanation what's going on.
1) When start dumping we detect vvar zone by reading /proc/pid/smap
and looking up for "[vvar]" token. Note the vvar zone is mapped
by a kernel with PF/IO flags so we should not fail here.
Also it's assumed that at least for now kernel won't be changed
much and [vvar] zone always follows the [vdso] zone, otherwise
criu will print error.
2) In previous commits we disabled dumping vvar area contents so
the restorer code never try to read vvar data but still we need
to map vvar zone thus vma entry remains in image.
3) As with previous vdso format we might have 2 cases
a) Dump and restore is happening on same kernel
b) Dump and restore are done on different kernels
To detect which case we have we parse vdso data from image
and find symbols offsets then compare their values with runtime
symbols provided us by a kernel. If they match and (!!!) the
size of vvar zone is the same -- we simply remap both zones
from runtime kernel into the positions dumpee had at checkpoint
time. This is that named "inplace" remap (a).
If this happens the vdso_proxify() routine drops VMA_AREA_REGULAR
from vvar area provided by a caller code and restorer won't try
to handle this vma. It looks somehow strange and probably should
be reworked but for now I left it as is to minimize the patch.
In case of (b) we need to generate a proxy. We do that in same
way as we were before just include vvar zone into proxy and save
vvar proxy address inside vdso mark injected into vdso area. Thus
on subsequent checkpoint we can detect proxy vvar zone and rip
it off the list of vmas to handle.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently we build vDSO handling code for all archs provided
in the source code having some "common" parts inside pie/vdso.c,
pie/vdso-stub.c, vdso-stub.c and vdso.c. This were more or
less well but in new linux kernels (starting from 3.16 presumably)
the vDSO has been significantly reworked so every architecture
must have own vDSO handling engine (just like the kernel does).
So in this patch we move vDSO code to arch specific and because
aarch64 actually doesn't implement proxification yet due to
kernel restrictions -- we drops it out. When there will be
kernel support we bring it back in proper arch/aarch64
implementation.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Alexander Kartashov <alekskartashov@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
vmsplice doesn't work for such VMA-s.
This flags is set in a kernel function remap_pfn_range()
(remap kernel memory to userspace), which is widely used by device
drivers to provide direct access to a device memory.
Reported-by: J F <jgmb45@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
"relative path" is absolute path with dot at the beginning.
We already use relative paths on restore. In this patch we add "."
on dump too. It's convinient, because we needed to add dot each time
when we want to access this mount point.
Before this patch we had to created a temporary copy.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It will be used for restoring files from proper mounts.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We are going to parse fdinfo for getting mnt_id,
so we can take there pos and flags and don't call
fcntl and lseek for that.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
An mmaped file is opened O_RDONLY or O_RDWR depending on the permissions
on the first vma dump_task_mm() encounters mapping that file. This
causes two problems:
1. If a file has multiple MAP_SHARED mappings, some of which are
read-only and some of which are read-write, and the first encountered
mapping happens to be read-only, the file will be opened O_RDONLY
during restore, and mmap(PROT_WRITE) will fail with EACCES, causing
the restore to fail.
2. If a file is opened read-write and mapped read-only, it will be
opened O_RDONLY during restore, so restore will succeed, but
mprotect(PROT_WRITE) on the read-only mapping after restore will
fail.
To fix both of these, record open flags per-vma based on the presence of
VM_MAYWRITE in smaps.
Signed-off-by: Jamie Liu <jamieliu@google.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
ID: 0
signal: 26/ (null)
notify: signal/pid.5954
ClockID: 1
fscanf "%p" doesn't handle "(null)".
https://bugzilla.openvz.org/show_bug.cgi?id=2894
v2: make the original scanf be %d/%s and then additionally
parse the obtained string
v3: don't use strstr
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We spend a lot of time reading the /proc/$pid/smaps file. The time
is spent in two places:
1 kernel puts too many info into it
2 fgets pulls info in 1024-bytes chunks, info about one vma is
typically bigger (up to 3k bytes) thus we call read() ~3 times
per one vma, which increases the amount of time spent in kernel
to re-fill this info
Setting the internal buffer to PAGE_SIZE size reduces the amount of
read()-s on ~60% during basic container dump. Setting bigger buffer
doesn't work, as kernel's seq file engine feeds at most one page of
data per read syscall regardless of the buffer size.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
On restore we only need to know currnet task mappings' start and end
to find where to put the restorer blob. And since the smaps file in
/proc/pid is up to 3 times slower, than the maps one, it makes
perfect sense just to parse the latter one.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
On restore we will read all VmaEntries in one big MmEntry object,
so to avoif copying them all into vma_areas, make them be pointable.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In /proc/<pid>/smaps/ output we may omit testing
for capital hex letters, since we know the format
kernel provides.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When parsing mappings in proc, we fstat vm file, later,
when dumping it, we stat it again to fill fd_parms.
The 2nd stat is not required, we can keep the stat in
vma_area.
This removed 35% of all stat calls on dump of basic container.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Quite a lot of VMAs in tasks map the same file with different
perms. In that case we may skip opening all these files, but
"borrow" one from the previous VMA parsed.
There's little sense in seeking more that just previous VMA,
as same files are rarely (can be though) mapped in different
locations.
After this on a basic Centos6 container the number of opens and
stats in this function drops from ~1500 to ~500.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Bug was introduced by on-disk-irmap-cache patch. The proc-parse
routine allocates memory for handle, calls ->cb then frees handle.
The problem is that the cb in case of pre-dump saves the handle
for future reference. So, in this future handle's mem happen to
be corrupted.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The existing code opens "self" and parses what's in there,
just twist the code a little to accept generic pid.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This helper will cause BTRFS engine to collect all subvolumes.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If we fail in xmalloc the function occasionally return
0 meaning that everything is fine. Don't do that, wait
until routine complete.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We will need it for additional handling once parsing
of mount entry is complete (in particular btrfs requires
additional processing to figure out subvolumes names).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
crtools.h is too heavy to be included in many sources
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This vma looks like VSYSCALL on x86. We don't need to dump and restore it.
Currently this vma is dumped and restored as a private vma, but it is not
remmaped in a correct place:
Restore
--- dump/pipe00/6392/1/dump.maps 2013-09-23 12:49:19.436816192 +0000
+++ dump/pipe00/6392/1/restore.maps 2013-09-23 12:49:20.276766356 +0000
@@ -6,5 +6,6 @@ e05000-e26000
4009d000-4009f000
400a0000-400aa000
400b8000-401e7000
+b6d6f000-b6d70000
be838000-be859000
ffff0000-ffff1000
ERROR: Sets of mappings differ:
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
parse_thread allocated a buffer for threads and then it initialized read
pid for each thread.
Now we want to use it on restore and in this moment we already have
a buffer with initialized virt pid-s, so we need to initialize read
pid-s only.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It will be used in cr-restore.c for stopping threads on the exit from
sigreturn.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The kernel logic is described in v2.6.36-rc1-161-g7798330:
"If we've split the stack vma, only the lowest one has the guard page."
https://bugzilla.openvz.org/show_bug.cgi?id=2715
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
timer is not freed in case of eof.
CID 1042301 (#1 of 1): Resource leak (RESOURCE_LEAK)
15. leaked_storage: Variable timer 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>
parse_posix_timers should not call ferror if fopen returned NULL.
Reported-by: Adrian Reber <adrian@lisas.de>
Cc: Pavel Tikhomirov <snorcht@gmail.com>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
1st stage is -- creating the timers. It may fail if kernel
allocated IDs in a manner we don't expect or runs out of
memory.
2nd stage is -- arm the timers. It cannot fail, since we've
validated the timespecs in advance and should happen after
we've waited for all the other tasks to complete the restore.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The [vdso] mark in procfs output is not reliable,
so since we know which prot it should has, escape
obvious mishints.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
