- 07 Oct, 2014 3 commits
-
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org>
-
Tycho Andersen authored
Previously we were trying to copy the root cg properties recursively to attempt to correct invalid restores. However, based on some ML discussion, we should only restore exactly what was dumped. Users need to set up their cg heirarchies correctly (that is, they should not set up any options in the parent that would conflict with what was dumped) in order to restore successfully. Signed-off-by:
Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by:
-
Tycho Andersen authored
This commit is in preparation for the (hopefully last :) restore special cpuset patch. Previously, we installed the cgroup service fd after calling prepare_cgroup_dirs, which meant that we had to carry around the temporary directory name in order to put things in the right place. The restore_cgroup_prop function uses the cg service fd instead of carrying around the full path. This means that we can't sue restore_cgroup_prop, without first sanitizing the path. Instead, we install the service fd before calling prepare_cgroup_dirs, and all the code just references that instead of carrying around the temporary path. Signed-off-by:
-
- 03 Oct, 2014 15 commits
-
-
Nicolas Dichtel authored
Error was: maps02.c: In function ‘main’: maps02.c:57:74: error: ‘MADV_DONTDUMP’ undeclared (first use in this function) maps02.c:57:74: note: each undeclared identifier is reported only once for each function it appears in make: *** [maps02] Error 1 ERROR: fail to start /home/root/criu/test/zdtm/live/static/maps02 Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
-
Cyrill Gorcunov authored
Add missing implementations for ARM platforms. Reported-by: Mr. Travis Signed-off-by:
-
Cyrill Gorcunov authored
On Tue, Sep 30, 2014 at 09:18:55PM +0400, Cyrill Gorcunov wrote: > Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Updated >From fea15362291a525f4b00f7e070968c6890cc831e Mon Sep 17 00:00:00 2001 From: Cyrill Gorcunov <gorcunov@openvz.org> Date: Fri, 19 Sep 2014 17:56:11 +0400 Subject: [PATCH 12/12] cpuinfo: rpc -- Add CPUINFO_DUMP/CPUINFO_CHECK commands Signed-off-by:
-
Cyrill Gorcunov authored
On Wed, Oct 01, 2014 at 05:51:09PM +0400, Pavel Emelyanov wrote: > > Yes, what you've been expecting? > > if (!strcmp(argv[optind])) > return cpu_cap_check() > > or smth like this. updated. So if it become confusing -- feel free to merge [1;9] and ping me to resend the rest, or pick up from attachements. >From 6af96ff63ac82f9566c3cba9c116dc67698c9797 Mon Sep 17 00:00:00 2001 From: Cyrill Gorcunov <gorcunov@openvz.org> Date: Tue, 30 Sep 2014 18:33:40 +0400 Subject: [PATCH] cpuinfo: Add "cpuinfo [dump|check]" commands They allow to validate cpuinfo information without running complete dump/restore actions. Signed-off-by:
-
Cyrill Gorcunov authored
On Wed, Oct 01, 2014 at 04:57:40PM +0400, Pavel Emelyanov wrote: > On 10/01/2014 01:07 AM, Cyrill Gorcunov wrote: > > On Tue, Sep 30, 2014 at 09:18:53PM +0400, Cyrill Gorcunov wrote: > >> If a user requested criu to dump cpuinfo image then we > >> write one on dump and verify on restore. At the moment > >> we require all cpu feature bits to match the destination > >> cpu in a sake of simplicity, but in future we need deps > >> engine which would filer out bits and test if cpu we're > >> restoring on is more capable than one we were dumping at > >> allowing to proceed restore procedure. > >> > >> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> > > > > Updated to new img format Something like attached? >From 59272a9514311e6736cddee08d5f88aa95d49189 Mon Sep 17 00:00:00 2001 From: Cyrill Gorcunov <gorcunov@openvz.org> Date: Thu, 25 Sep 2014 16:04:10 +0400 Subject: [PATCH] cpuinfo: x86 -- Add dump and validation of cpuinfo image If a user requested criu to dump cpuinfo image then we write one on dump and verify on restore. At the moment we require all cpu feature bits to match the destination cpu in a sake of simplicity, but in future we need deps engine which would filer out bits and test if cpu we're restoring on is more capable than one we were dumping at allowing to proceed restore procedure. Signed-off-by:
-
Cyrill Gorcunov authored
At the moment only x86 is covered, ARM needs own handler. Signed-off-by:
-
Cyrill Gorcunov authored
Instead of parsing procfs lets use native cpuid(), it's a way faster. The dark side is that the kernel may disable some of features via bootline options even if they are present on hardware but for us it's fine -- we will be testing hardware cpu for features anyway. The X86_FEATURE_ bits are gathered from two sources: linux kernel and cpu specifications. Signed-off-by:
-
Cyrill Gorcunov authored
We will use them to fetch cpu caps. Signed-off-by:
-
Cyrill Gorcunov authored
We will need them to carry CPU's caps. Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
They will serve to choose capability level when migrating images between various hardware nodes. Note it's bare functionality introduced in this commit, the real implementation is in next patches. Signed-off-by:
-
Cyrill Gorcunov authored
This slightly changes the visible API, but i think it's safe now. The idea behind it to make single --cpu-cap to indicate "--cpu-cap all". Signed-off-by:
-
Cyrill Gorcunov authored
It's redundant, should be cpu local. Signed-off-by:
-
Cyrill Gorcunov authored
It's simply a wrapper over cpu_has_feature, so use this it directly instead. Signed-off-by:
-
Cyrill Gorcunov authored
This is convenient when need to lookup into debug prints and check which mount point were used somewhere else (in particular I will need @mnt_id in tty code so on error I can easily figure out which mountpoint has been used). No func changes. Signed-off-by:
-
- 02 Oct, 2014 6 commits
-
-
Andrey Vagin authored
* check page server * check snapshots * check a few iterations of dump/restore Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Tycho Andersen authored
The symptom of this bug was that users restoring tasks to a nested cgroup where the top level group was created by criu (and not previously configured) e.g. cpuset:/lxc/u1 would get an ENOSPC. criu would try to copy the special properties into /lxc/u1 directly and (silently) fail, and then tried to copy the task into the cg and fail with ENOSPC: ENOSPC Attempted to write(2) an empty cpuset.cpus or cpuset.mems setting to a cpuset that has tasks attached. Fixing the silent failure to a loud failure, it gave EACCES: EACCES Attempted to add, using write(2), a CPU or memory node to a cpuset, when that CPU or memory node was not already in its parent. So, we need to copy the the special props down the entire tree. Additionally, we shouldn't copy props directly from the top, since some intermediate point in the tree could add restrictions. We first walk back up the tree to find the first point where the props are empty, and then copy that parent's props all the way down. Signed-off-by: -
Cyrill Gorcunov authored
No need to invent new error codes here, simply use ERR_PTR/IS_ERR_OR_NULL and such. Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by: -
Tycho Andersen authored
We're using NULL as a sentinel here to indicate that we shouldn't restore any cgroup properties. We should make sure that we don't leak this information and instead check the n_properties field, which we should also set correctly. Signed-off-by:
-
Pavel Emelyanov authored
On pre-dump we collect only two namespaces -- the mnt one for criu and mnt one again for root task. This is not correct. We need all mount namespaces to make the irmap generation work properly and we need all net namespaces to have parasite sockets created. Signed-off-by:
-
- 01 Oct, 2014 11 commits
-
-
Pavel Emelyanov authored
Now we have netns on pstree-item and have the place where to pre-create daemon socket in needed namespace. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Will be needed for parasite sockets. Signed-off-by: -
Pavel Emelyanov authored
To make it possible to get ns_id object together with its ID. Signed-off-by: -
Pavel Emelyanov authored
Empty for now, will be filled soon. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
The setns() syscall (called by switch_ns()) can be extremely slow. If we call it two or more times from the same task the kernel will synchonously go on a very slow routine called synchronize_rcu() trying to put a reference on old namespaces. To avoid doing this more than once I propose to create all per-ns sockets in one place with one setns call. In this patch there's on nl diag socket used to collect other sockets is created this way. Signed-off-by: -
Pavel Emelyanov authored
Right now we don't support multiple net namespaces, but some day we will. Other than this we have a logic to distinguish cases with no namespaces vs one namespace, so this walking already makes sence. Signed-off-by: -
Pavel Emelyanov authored
And move sockets collection there. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
We have a use-after-free in predump code: 1st the free_pstree() is called in pre_dump_tasks(), then we go to irmap_predump_run() which may call the lookup_irmap() which, in turn, dereferences the root_item to get the root mount ns fd. But the problem is bigger than that. After we've released the tasks (done before freeing pstree on predump) we can no longer access them by PIDs, so keeping the root-item after irmap scan is not a fix. Fix is to get the root fd before releasing the tasks and using one in irmap scanner. Caught recently on iterative inotify_irmap test. Signed-off-by:
-
- 30 Sep, 2014 5 commits
-
-
Andrey Vagin authored
man 2 open: """ mode specifies the permissions to use in case a new file is cre‐ ated. This argument must be supplied when O_CREAT or O_TMPFILE is specified in flags; """ Cc: Konstantin Neumoin <kneumoin@parallels.com> Signed-off-by:
-
Andrey Vagin authored
Reported-by:
Konstantin Neumoin <kneumoin@parallels.com> Cc: Konstantin Neumoin <kneumoin@parallels.com> Signed-off-by:
-
Pavel authored
Signed-off-by: -
Andrey Vagin authored
Travis CI is configured by adding a file named .travis.yml, which is a YAML format text file, to the root directory of the GitHub repository.[5] Travis CI automatically detects when a commit has been made and pushed to a GitHub repository that is using Travis CI, and each time this happens, it will try to build the project and run tests. """ https://en.wikipedia.org/wiki/Travis_CI Currently Travis CI builds criu for x86_64 and ARM v2: move travis-ci.sh in scripts v3: fix path to the script in the script Signed-off-by:
-
Pavel Emelyanov authored
The restore times look like Before patch: futex: 370 3.554482 (84.2%) umount: 41 0.234796 (5.6%) read: 4737 0.113987 (2.7%) recvmsg: 43 0.100083 (2.4%) wait4: 10 0.033344 (0.8%) After patch: futex: 187 1.547642 (72.9%) umount: 41 0.234595 (11.0%) recvmsg: 43 0.075738 (3.6%) flock: 42 0.038696 (1.8%) clone: 35 0.037699 (1.8%) Most of the time we wait for other processes to restore, but that's OK (would only affect parallel restore). And we see that read-s really go away (onto 7th position). Signed-off-by:
-
