The restorer blob may die silently due to anything:
- Segmentation fault
- OOM killer
- User-sended SIGKILL
- Child CRIU restorer did't abort futex on error path (and exited)
We should terminate the restoring process and avoid locking
self up on waiting for died restoree.
Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.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>
To check that jump trampolines to rt-vdso works.
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
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>
Parasite should cleanup after fauilure and remove read-protection
from VMAs. Check it with maps00 test & fault injection.
Tested on travis with some addition:
python test/zdtm.py run -t zdtm/static/maps00 --fault 3 --keep-going --report report -f h || false
https://travis-ci.org/0x7f454c46/criu/jobs/119252291
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Dmitry Safonov <dsafonov@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>
