Container runtimes like CRI-O and containerd utilize the freezer cgroup
to create a consistent snapshot of container root filesystem (rootfs)
changes. In this case, the container is frozen before invoking CRIU.
After CRIU successfully completes, a copy of the container rootfs diff
is saved, and the container is then unfrozen.
However, the `cuda-checkpoint` tool is not able to perform a 'lock'
action on frozen threads. To support GPU checkpointing with these
container runtimes, we need to unfreeze the cgroup and return it to its
original state once the checkpointing is complete.
To reflect this new behavior, the following changes are applied:
- `dont_use_freeze_cgroup(void)` -> `set_compel_interrupt_only_mode(void)`
- `bool freeze_cgroup_disabled` -> `bool compel_interrupt_only_mode`
- `check_freezer_cgroup(void)` -> `prepare_freezer_for_interrupt_only_mode(void)`
Note that when `compel_interrupt_only_mode` is set to `true`,
`compel_interrupt_task()` is used instead of `freeze_processes()`
to prevent tasks from running during `criu dump`.
Fixes: #2508
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
This patch optimizes shell code as reading a single file as input using a 'cat' command to a program.
It is considered to be a Useless Use of Cat (UUOC).
It's more efficient to simply use redirection.
However, in some cases, even using the redirection operator '<' seems unnecessary.
Signed-off-by: KKrypt <sankalpacharya1211@gmail.com>
It looks like we've got broken fhandles from fdinfo
for inotifies/fanotifies for btrfs. I will look into that.
Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
Looking at CI logs there are often messages like:
"[WARNING] Option --keep-going is more useful when running multiple tests"
This commit removes '--keep-going' from single zdtm test runs.
Signed-off-by: Adrian Reber <areber@redhat.com>
We permanently have issues like this:
./test/jenkins/criu-iter.sh: 3: source: not found
It looks like a good idea to use one shell to run our jenkins scripts.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Test for previously fixed bugs for vdso-trampolines insertion:
- unmapping original vvar (which went unnoticed)
- leaving rt-vvar after each C/R cycle and resulting pollution
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
link-remap files has to be deleted only if processes have been
restored successfully. Otherwise we can want to repeat an attempt,
but it is imposible if some link-remap files were deleted.
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
By default criu tries to create parasite mem with memfd syscall,
which is present in many systems. Let's check also the legacy way.
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
add options --keep-going and --report (if it was absent)
to run full testrun with report creation
Signed-off-by: Sergey Bronnikov <sergeyb@openvz.org>
Acked-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
From code coverage report, we found that inotify_irmap doesn't test irmap
cache, because we is always able to resolve path from /proc/PID/fd/X.
Current view: top level - criu - irmap.c (source / functions) Hit Total Coverage
Test: criu.info Lines: 40 223 17.9 %
Date: 2016-03-16 Functions: 4 13 30.8 %
This series introduces a new fault to emulate a situation
when a file can't be opened by handle and we have to find
it in the irmap cache/
It's required to test irmap cache. I don't know how to force it
without this patch. Each time when a file can be opened by handle,
its path can be resolved via /proc/PID/fd/X.
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
