On Thu, Mar 13, 2014 at 02:30:50PM +0400, Cyrill Gorcunov wrote:
>
> This image is deprecated now so move it out of
> _CR_FD_TASK thus we won't be even generating it
> on the dump.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Updated
>From cb9c3953beac7d42de80635e7a6e537cc867c479 Mon Sep 17 00:00:00 2001
From: Cyrill Gorcunov <gorcunov@openvz.org>
Date: Thu, 13 Mar 2014 14:24:50 +0400
Subject: [PATCH 7/7] rlimit: Move CR_FD_RLIMIT out of _CR_FD_TASK
This image is deprecated now so move it out of
_CR_FD_TASK thus we won't be even generating it
on the dump.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This allows us to distinguish the situation where image
to be opened is missing but optional, thus no error message
should be printed.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's going to be used for restoring namespaces. For example we need to
enumirate the ns_ids list for restoring mount namespaces.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The implementation of bit operations for ARM isn't actually
architecture-specific so it would rather be shared with
the upcoming port for AArch64 that won't provide optimized
implementation of bit operations.
Signed-off-by: Alexander Kartashov <alekskartashov@parallels.com>
Reviewed-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
when decide that data is no longer needed, there are two cases:
-if data neighbours previous block of "no needed" data, extend bunch
block(it holds begining and size of concequent "no needed" data) by
length of curent block and go next.
-if data not neighbours bunch block(or bunch block size will be bigger
than MAX_BUNCH_SIZE), than we punch bunch block and set bunch block
to curent block.
in the end make cleanup to punch last bunch block.
changes in v1:
punch_hole takes whole page_read
make restriction more precise
Signed-off-by: Tikhomirov Pavel <snorcht@gmail.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When migrating container with copying its FS, the inode numbers
and thus their handles wil change. This will make the restore of
inotify/fanotify fail, since they do it via fhandles.
We've already faced the problems with fsnotifies on NFS -- they
don't work there. To address this an irmap cache is created on
pre-dump, so to resolve the issue with changed inodes during
migration, we can force the irmap cache build.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This option will serve to manage CPU capabilities
to be matched/ignored on restore procedure. At the
moment we introduce 'fpu','all' capability arguments.
By default 'all' is set.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Not all distros provide magic numbers we might need
during build procedure, thus provide own definitions
in one known place.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Otherwise if the mark is set up on link we end
with -ELOOP error trying to open it. Thus, use
O_PATH pointing the kernel that we're not going
to read/write this descriptor.
Repored-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
At the moment we are using 4K pages all the time,
so instead of copying code over all archs we're
supporting -- add asm-generic/page.h header.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We have #define BUG() BUG_ON(true) here, where 'true'
is defined in stdbool header, so to be able to include
bug.h on its own -- include needed header inplace.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
These are needed to compile project on CentOS 6.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Pavel reported that in case if there a big number
of small vmas present in the dumpee we're reading
/proc/pid/pagemap too frequently.
To speedup this procedue we inroduce pagemap cache.
The interface is:
- pmc_init/pmc_fini for cache initialization and freeing
- pmc_get_map to retrieve specific PMEs array for VMA area
v2:
- Move internal constants to pagemap-cache.c
- Make PAGEMAP_LEN to accept virtual address/size
- Don't adjust low bound in caching mode to save a couple of code bytes
Reported-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We want to write into empty image files, so we
unlink them before dumping into. Let's O_TRUNC
it instead.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
PIPE_MAX_SIZE is calculated according with the kernel code.
PPB_IOV_BATCH has been taken from my mind.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The problem is that vmsplice() to a big pipe fails very often.
The kernel allocates a linear chunk of memory for pipe buffer
descriptos, but a big allocation in kernel can fail.
So we need to restrict maximal capacity of pipes. But the number of
pipes is restricted too, so we need to split dumping memory on chunks.
In this patch we calculates the pipe size for which vmsplice() will not
fail.
v2: s/batch/chunk and a few other small fixes
v3: Remove callbacks from page_pipes and reuse pipes
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The makefile includes need to be moved for everything to be
defined properly when the configure tests run.
The Ubuntu 12.04 x86_64 GCC and Linaro's 13.08 and newer AArch64
GCC's have the if_packet.h kernel header, but as of 13.12,
the Linaro AArch32 GCC does not.
Change-Id: I363c43fdb81b028f99aac77e15bff9462c87af4b
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
CONFIG_HAS_PEEKSIGINFO_ARGS is used there.
Cc: Christopher Covington <cov@codeaurora.org>
Reported-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Same for previous patch with vmas -- we do it on collect and
on real open. Just put the pointer on fifo_info structure.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We do it first -- on collect, second -- on restore. The
2nd lookup is excessive, we can put fd pointer on vm_area
at lookup and reuse one later.
Signed-off-by: Pavel Emelyanov <xemul@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>
If a file mmaped or pointed by exe link is unlinked, we will
generate a ghost file for it. On restore the ghost file will
be created with the users counter 1 and the very first open
(e.g. for mmap) will unlink the file.
Handle this by bumping up user counter for every mapping
pointing on the file.
This appeared after previous patches that packed the reg-files
image. Before it each vma and exe link created separate entry
in the reg-files image.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
For unlinked opened and mmaped files we'd need to
care about remaps, for this the callback with both
file_desc and fdinfo_list_entry will be required.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If we specify log level to none (0) the result is LOG_INFO (2).
Acked-by: Andrew Vagin <avagin@parallels.com>
Acked-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When writing VMAs we perform too many small writes into vma-.img files.
This can be easily fixed by moving the vma-s into mm-s, all the more
so they cannot be splitted from each other.
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>
Currently we check PTRACE_PEEKSIGINFO and if it's defined in a system
header, we suppose that ptrace_peeksiginfo_args is defined there too.
But due to a bug in glibc, this check doesn't work. Now we have F20,
where ptrace_peeksiginfo_args is defined in sys/ptrace and F21 where
it isn't defined.
commit 9341dde4d56ca71b61b47c8b87a06e6d5813ed0e
Author: Mike Frysinger <vapier@gentoo.org>
Date: Sun Jan 5 16:07:13 2014 -0500
ptrace.h: add __ prefix to ptrace_peeksiginfo_args
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Right now we do it two times -- on shmem prepare and
on the restore itself. Make collection only once as
we do for fdinfo-s -- root task reads all stuff in and
populates tasks' rst_info with it.
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>
The is_foo_link readlinks the lfd to check. This makes
anon-inodes dumping readlink several times to find proper
dump ops. Optimize this thing.
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>
