- 14 Oct, 2014 6 commits
-
-
Pavel Emelyanov authored
Signed-off-by:Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by: -
Andrey Vagin authored
Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Tycho Andersen authored
See the comment below for an explanation of what is going on. We will ultimately need to handle dumping the netlink data, but I think it is good to prevent injecting events into the stream during a dump. So we pre-load the modules, even though it isn't very pretty. Signed-off-by:
Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by:
-
Andrey Vagin authored
They are not used outside. Signed-off-by:
-
Andrey Vagin authored
We don't set breakpoints for zombies. Signed-off-by:
-
- 09 Oct, 2014 2 commits
-
-
Andrey Vagin authored
I found this solution in the LXC code. We can open the old root, call pivot_root(".", "."), call fchdir to the old root and call umount("."). Now restore will not fail, if the root is read-only. In addition it's a bit faster. Signed-off-by: -
Konstantin Neumoin authored
The main problem with the test that it's never 'fail'. Test can only 'pass' or hangs. Signed-off-by:
Konstantin Neumoin <kneumoin@parallels.com> Acked-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
-
- 08 Oct, 2014 8 commits
-
-
Pavel Tikhomirov authored
Signed-off-by:
Pavel Tikhomirov <ptikhomirov@parallels.com> Signed-off-by:
-
Tycho Andersen authored
TASK_HELPERs are created with CLONE_FILES, so if we always close the cg yard here, it will close it for the other helpers and cause problems. Instead, we close it much later, in code only called by alive tasks, to ensure that there is no conflict. Signed-off-by:
-
Cyrill Gorcunov authored
Actually these @locked and @packet_mode are valid for unix98 ptys only so since moving them into @tty_pty_entry is impossible at least lets comment this. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
- parse_index -> parse_pty_index since it's PTY specific - pty_is_master -> tty_is_master because it will test not only PTY peers but other types as well - pty_is_hung -> tty_is_hung for same reason Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
For readability sake. Signed-off-by:
-
- 07 Oct, 2014 7 commits
-
-
Christopher Covington authored
TASK_SIZE for AArch64 may be any of several options between (1 << 39) and (1 << 48), inclusive, depending on kernel configuration. Go back to just checking the most significant bit, as was done before commit 3f12d688 was made to accomodate 32-bit ARM (before mmap_seized got architecture-specific implementations). This fixes the following error for AArch64 kernels with CONFIG_ARM64_64K_PAGES=y. Error (parasite-syscall.c:1105): Can't allocate memory for parasite blob (pid: 104) Signed-off-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
-
Andrey Vagin authored
After changing an owner the current user will not be able to remove or change the directory. It isn't convenient. Reported-by:
-
Andrey Vagin authored
zdtm-pre-dump, zdtm-snapshot, zdtm-iter, zdtm execute pipe00, so these targets should be executed one by one. Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by:
-
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 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:
-
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 2 commits
-
-
Andrey Vagin authored
* check page server * check snapshots * check a few iterations of dump/restore 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:
-
