This is a preferred way of fixing SC2086 shellcheck warning.
Note that since ZDTM_OPTS is passed as a string (via make or docker),
we are converting it to an array using read -a.
Remove all "shellcheck disable=SC2086" annotations.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Instead of using shellcheck v0.7.2 from fedora repo,
let's install the latest version (v0.8.0).
This allows to remove some "shellcheck disable=..." annotations,
and (I hope) better checking quality overall.
While at it, remove findutils from dnf install as this package is
already installed.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
When we restore a shell-job we would inherit tty-s, so even if we don't
have a right mount for it in container on dump, on restore it should
just be right.
Else when dumping second time via criu-ns we get:
(00.005678) Error (criu/files-reg.c:1710): Can't lookup mount=29 for fd=0 path=/dev/pts/20
Fixes: #1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
When we are restoring in new pidns we specifically do setsid() from
criu-ns init so that sids of restored tasks are non-zero in this pidns
and on next dump CRIU would not have problems with zero sids, see [1].
But after this CRIU tries to inherit and setup a tty for the restored
process, and it fails to set it's process group via TIOCSPGRP to be a
foreground group for it's tty, because tty already is a controlling tty
for other session (which we had before setsid).
So to make it restore we need to reset tty to be a controlling tty of
criu-ns init via TIOCSCTTY before calling criu.
Else when restoring first time via criu-ns (from criu-ns dump) we get:
Error (criu/tty.c:689): tty: Failed to set group 40816 on 0: Inappropriate ioctl for device
https://github.com/checkpoint-restore/criu/issues/232 [1]
v2: add why and what comment in code, set controlling tty only for
--shell-job and fail if stdin is not a tty.
Fixes: #1893
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
A recent change in glibc introduced `enum fsconfig_command` [1] and as a
result the compilation of criu fails with the following errors
In file included from criu/pie/util.c:3:
/usr/include/sys/mount.h:240:6: error: redeclaration of 'enum fsconfig_command'
240 | enum fsconfig_command
| ^~~~~~~~~~~~~~~~
In file included from /usr/include/sys/mount.h:32:
criu/include/linux/mount.h:11:6: note: originally defined here
11 | enum fsconfig_command {
| ^~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:242:3: error: redeclaration of enumerator 'FSCONFIG_SET_FLAG'
242 | FSCONFIG_SET_FLAG = 0, /* Set parameter, supplying no value */
| ^~~~~~~~~~~~~~~~~
criu/include/linux/mount.h:12:9: note: previous definition of 'FSCONFIG_SET_FLAG' with type 'enum fsconfig_command'
12 | FSCONFIG_SET_FLAG = 0, /* Set parameter, supplying no value */
| ^~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:244:3: error: redeclaration of enumerator 'FSCONFIG_SET_STRING'
244 | FSCONFIG_SET_STRING = 1, /* Set parameter, supplying a string value */
| ^~~~~~~~~~~~~~~~~~~
criu/include/linux/mount.h:14:9: note: previous definition of 'FSCONFIG_SET_STRING' with type 'enum fsconfig_command'
14 | FSCONFIG_SET_STRING = 1, /* Set parameter, supplying a string value */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:246:3: error: redeclaration of enumerator 'FSCONFIG_SET_BINARY'
246 | FSCONFIG_SET_BINARY = 2, /* Set parameter, supplying a binary blob value */
| ^~~~~~~~~~~~~~~~~~~
criu/include/linux/mount.h:16:9: note: previous definition of 'FSCONFIG_SET_BINARY' with type 'enum fsconfig_command'
16 | FSCONFIG_SET_BINARY = 2, /* Set parameter, supplying a binary blob value */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:248:3: error: redeclaration of enumerator 'FSCONFIG_SET_PATH'
248 | FSCONFIG_SET_PATH = 3, /* Set parameter, supplying an object by path */
| ^~~~~~~~~~~~~~~~~
criu/include/linux/mount.h:18:9: note: previous definition of 'FSCONFIG_SET_PATH' with type 'enum fsconfig_command'
18 | FSCONFIG_SET_PATH = 3, /* Set parameter, supplying an object by path */
| ^~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:250:3: error: redeclaration of enumerator 'FSCONFIG_SET_PATH_EMPTY'
250 | FSCONFIG_SET_PATH_EMPTY = 4, /* Set parameter, supplying an object by (empty) path */
| ^~~~~~~~~~~~~~~~~~~~~~~
criu/include/linux/mount.h:20:9: note: previous definition of 'FSCONFIG_SET_PATH_EMPTY' with type 'enum fsconfig_command'
20 | FSCONFIG_SET_PATH_EMPTY = 4, /* Set parameter, supplying an object by (empty) path */
| ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:252:3: error: redeclaration of enumerator 'FSCONFIG_SET_FD'
252 | FSCONFIG_SET_FD = 5, /* Set parameter, supplying an object by fd */
| ^~~~~~~~~~~~~~~
criu/include/linux/mount.h:22:9: note: previous definition of 'FSCONFIG_SET_FD' with type 'enum fsconfig_command'
22 | FSCONFIG_SET_FD = 5, /* Set parameter, supplying an object by fd */
| ^~~~~~~~~~~~~~~
/usr/include/sys/mount.h:254:3: error: redeclaration of enumerator 'FSCONFIG_CMD_CREATE'
254 | FSCONFIG_CMD_CREATE = 6, /* Invoke superblock creation */
| ^~~~~~~~~~~~~~~~~~~
criu/include/linux/mount.h:24:9: note: previous definition of 'FSCONFIG_CMD_CREATE' with type 'enum fsconfig_command'
24 | FSCONFIG_CMD_CREATE = 6, /* Invoke superblock creation */
| ^~~~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:256:3: error: redeclaration of enumerator 'FSCONFIG_CMD_RECONFIGURE'
256 | FSCONFIG_CMD_RECONFIGURE = 7, /* Invoke superblock reconfiguration */
| ^~~~~~~~~~~~~~~~~~~~~~~~
criu/include/linux/mount.h:26:9: note: previous definition of 'FSCONFIG_CMD_RECONFIGURE' with type 'enum fsconfig_command'
26 | FSCONFIG_CMD_RECONFIGURE = 7, /* Invoke superblock reconfiguration */
This patch adds definition for FSOPEN_CLOEXEC to solve this problem. In particular,
sys/mount.h includes ifndef check for FSOPEN_CLOEXEC surrounding `enum fsconfig_command`.
[1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7eae6a91e9b1670330c9f15730082c91c0b1d570
Reported-by: Younes Manton (@ymanton)
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
This patch changes top-level OpenJ9 filename and data references to Java
to make them generic and launches tests against both HotSpot and OpenJ9
JVMs.
Signed-off-by: Younes Manton <ymanton@ca.ibm.com>
Semeru builds (which use OpenJ9 instead of HotSpot) are the successors
of AdoptOpenJDK's OpenJ9 builds.
Signed-off-by: Younes Manton <ymanton@ca.ibm.com>
We used to pull AdoptOpenJDK's OpenJ9 builds but switched to
Eclipse Temurin, which uses the HotSpot VM instead of OpenJ9.
Rename the corresponding Dockerfiles to hotspot.
Signed-off-by: Younes Manton <ymanton@ca.ibm.com>
The entry "build/" will ignore any directory named "build" at any level
of the source tree, including our scripts/build directory. We only want
to ignore the top-level build directory created by `make install`.
As the git manpage suggests, entries with slashes at the start or in the
middle will only match at the same level as the .gitignore, hence use
build/** instead.
Signed-off-by: Younes Manton <ymanton@ca.ibm.com>
This allows to make test code more compact:
if (ret == -1) {
pr_perror("XXX");
return 1;
}
vs
if (ret == -1)
return pr_perror("XXX");
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Before this change, CRIU would just lose that data upon migration. So
it's better to fail migration in this case.
To reproduce the bug one can:
1. Create an AF_UNIX socket and call listen on it.
2. Create a second AF_UNIX socket and call connect to the first one.
3. Send the data to the second socket.
4. Migrate.
5. Call accept on the first socket and then read. There would be no data
available.
It should be even possible to close the second socket before migration.
This would cause accept to hang because CRIU totally misses a closed
in-flight socket.
Signed-off-by: Michal Clapinski <mclapinski@google.com>
The x86 implement hardware breakpoint to accelerate the tracing syscall
procedure instead of `ptrace(PTRACE_SYSCALL)`. The arm64 has the same
capability according to <<Learn the architecture: Armv8-A self-hosted
debug>>[[1]].
<<Arm Architecture Reference Manual for A-profile architecture>[[2]]
illustrates the usage detailly:
- D2.8 Breakpoint Instruction exceptions
- D2.9 Breakpoint exceptions
- D13.3.2 DBGBCR<n>_EL1, Debug Breakpoint Control Registers, n
Note:
[1]: https://developer.arm.com/documentation/102120/0100
[2]: https://developer.arm.com/documentation/ddi0487/latest
Signed-off-by: fu.lin <fulin10@huawei.com>
Signed-off-by: Andrei Vagin <avagin@gmail.com>
Breakpoints are used to stop as close as possible to a target system call.
First, we don't need it after this point.
Second, PTRACE_CONT can't pass through a breakpoint on arm64.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
When delivering system call traps, set bit 7 in the signal number (i.e.,
deliver SIGTRAP|0x80). This makes it easy for the tracer to distinguish
normal traps from those caused by a system call.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
1. Rename CentOS 8 to CentOS Stream 8 (which it is).
2. Install junit_xml from the repo rather than via pip.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Mostly a copy-paste from the CentOS 8 task, with a few differences:
- Use dnf instead of yum
- Enable crb instead of powertools
- Different way of installing EPEL
- No need to switch to python3 as this is the default
- junit_xml is now available as an rpm
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
There is a race condition in docker/containerd that causes docker to
occasionally fail when starting a container from a checkpoint immediately
after the checkpoint has been created.
This problem is unrelated to criu and has been reported in
https://github.com/moby/moby/issues/42900
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
Let's use dynamic approach to detect built-in *libc rseq in all cases,
and "old" static approach as a fallback path if the user kernel
lacks support of ptrace_get_rseq_conf feature.
Suggested-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
Before this patch we assumed that CRIU is compiled against
the same GLibc as it runs with. But as we see from real
world examples like #1935 it's not always true.
The idea of this patch is to detect rseq configuration
for the main CRIU process and use it to unregister
rseq for all further child processes. It's correct,
because we restore pstree using clone*() syscalls,
don't use exec*() (!) syscalls, so rseq gets inherited
in the kernel and rseq configuration remains the same
for all children processes.
This will prevent issues like this:
https://github.com/checkpoint-restore/criu/issues/1935
Suggested-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
The result of check_aa_ns_dumping() is stored in kdat. Instead of doing
the same check twice - once on kerndat_init(), and again in
check_apparmor_stacking(), we can check the stored value.
Suggested-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
The feature check for AppArmor stacking was introduced in
commit:
8723e3f998
check: add a feature test for apparmor_stacking
However, on systems that don't support AppArmour, this check always
fails. As a result, `criu check --all` shows the following message:
Looks good but some kernel features are missing
which, depending on your process tree, may cause
dump or restore failure.
Reported-by: André Rösti (@andrej)
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
In commits [1, 2] the version of containerd installed by default in the
GitHub CI virtual environment was replaced with the latest release from
GitHub as a workaround to a bug in containerd. This bug has been fixed
sometime ago and the current default version of containerd (1.6.6) does
not require this workaround. However, with the latest release, the
containerd binaries uploaded on GitHub have been built for Ubuntu 22.04
[3]. Our tests are still running on Ubuntu 20.04 and this results in the
following error:
/usr/bin/containerd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/containerd)
/usr/bin/containerd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/bin/containerd)
[1] https://github.com/checkpoint-restore/criu/commit/046cad8
[2] https://github.com/checkpoint-restore/criu/commit/81a68ad
[3] https://github.com/containerd/containerd/commit/6b2dc9a37
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
There are several changes in glibc 2.36 that make sys/mount.h header
incompatible with kernel headers:
https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
This patch removes conflicting includes for `<linux/mount.h>` and
updates the content of `criu/include/linux/mount.h` to match
`/usr/include/sys/mount.h`. In addition, inline definitions sys_*()
functions have been moved from "linux/mount.h" to "syscall.h" to
avoid conflicts with `uapi/compel/plugins/std/syscall.h` and
`<unistd.h>`. The include for `<linux/aio_abi.h>` has been replaced
with local include to avoid conflicts with `<sys/mount.h>`.
Fixes: #1949
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
We need to pass environment variables from the CI environment to
distinguish between CI environments. However, when `sudo -E` is
used to run Podman it results in the XDG_RUNTIME_DIR environment
variable being set incorrectly that prevents Podman from running.
This patch fixes the following error in the GitHub Action virtual
environment:
error running container: error from /usr/bin/crun creating
container for [/bin/sh -c /bin/prepare-for-fedora-rawhide.sh]:
sd-bus call: Connection reset by peer
Fixes: #1942
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
I've been contributing to CRIU for sometime and I'm hoping that my
familiarity with the project would be sufficient to self-nominate as a
maintainer. I would like to help with code reviews, submitting patches,
implementing new features, and maintaining the project in general.
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
ghost_holes_large00 is a test which creates a large ghost sparse file with 1GiB
hole(pwrite can only handle 2GiB maximum on 32-bit system) and 8KiB data, criu
should be able to handle this kind of situation.
ghost_holes_large01 is a test which creates a large ghost sparse file with 1GiB
hole and 2MiB data, since 2MiB is larger than the default ghost_limit(1MiB),
criu should fail on this test.
v2: fix overflow on 32-bit arch.
Signed-off-by: Liang-Chun Chen <featherclc@gmail.com>
unlink_largefile test
In the past, the unlink_largefile test should be fail on large ghost file.
However, it used sparse file, it will pass in current criu, since the large
ghost sparse file issue was fixed.
So the crfail flag of this test should be removed.
Signed-off-by: Liang-Chun Chen <featherclc@gmail.com>
files-reg.c checks whether the file size is larger than ghost_limit with st_size
(in dump_ghost_remap), which can not deal with large ghost sparse file, since
its actual file size is not the same as what st_size shows.
Therefore, in this commit, I replace st_size with st_blocks, which shows the
actual file size. (1 block = 512B), thus criu can deal with large ghost sparse
file.
Signed-off-by: Liang-Chun Chen <featherclc@gmail.com>
This test specifically wants to create external bind-mount of "/" from
criu mntns to test mntns, and it wants "/" in criu mntns to be a shared
mount so that "external" mount in the test mntns is it's slave. This is
to triger specific dirname() resolution which happens only when sharing
restore is involved for external mounts, and only if rootfs is involved.
But initially I missed that when we create external mount in test's
temporary mntns it creates a propagation in criu mntns on top of root
mount. This mount may influence other tests restore as child mount in
root mount converts to locked child mount in criu service mntns (for uns
flavour) and when criu would restore root container mount it would fail
with EINVAL on non recursive bind with locked children.
To fix this mess we just need to prohibit propagating from tests
temporary mntns to criu mntns by making mounts slave.
Fixes: #1941
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
If root mount in criu mntns is slave, it would be slave of host mount
where criu is stored, so if someone mounts something in subdir of
{criu-dir}/test/ on host while tests are running this mount can
influence the test as it appears on top of root mount in criu mntns.
1) With mount-compat this mount can get into restored test mntns, which
means wrong restore, as this mount was not there on dump.
2) With mount-v2 this mount would just fail container restore, as root
container mount is mounted non-recursively to protect from unexpected
mounts appear after restore.
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Normally, vsyscall vma has VM_READ, VM_EXEC permission. However, when
CONFIG_LEGACY_VSYSCALL_XONLY=y, that vma only has VM_EXEC. This commit removes
the permission part when checking to skip vsyscall vma in x32 tests.
Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
Error from:
./test/zdtm.py run -t zdtm/static/fpu00 --fault 134 -f h --norst
(00.003111) Dumping GP/FPU registers for 56
(00.003121) Error (compel/arch/x86/src/lib/infect.c:310): Corrupting fpuregs for 56, seed 1651766595
(00.003125) Error (compel/arch/x86/src/lib/infect.c:314): Can't set FPU registers for 56: Invalid argument
(00.003129) Error (compel/src/lib/infect.c:688): Can't obtain regs for thread 56
(00.003174) Error (criu/cr-dump.c:1564): Can't infect (pid: 56) with parasite
See also:
145e9e0d8c6 ("x86/fpu: Fail ptrace() requests that try to set invalid MXCSR values")
145e9e0d8c
We decided to move from mxcsr cleaning up scheme and use mxcsr mask
(0x0000ffbf) as kernel does. Thanks to Dmitry Safonov for pointing out.
Tested-on: Intel(R) Xeon(R) CPU E3-1246 v3 @ 3.50GHz
Reported-by: Mr. Jenkins
Suggested-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
1. For some reason, Marier distribution headers
not correctly define __GLIBC_HAVE_KERNEL_RSEQ
compile-time constant. It remains undefined,
but in fact header files provides corresponding
rseq types declaration which leads to conflict.
2. Another issue, is that they use uint*_t types
instead of __u* types as in original rseq.h.
This leads to compile time issues like this:
format '%llx' expects argument of type 'long long unsigned int', but argument 5 has type 'uint64_t' {aka 'long unsigned int'}
and we can't even replace %llx to %PRIx64 because it will break
compilation on other distros (like Fedora) with analogical error:
error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘__u64’ {aka ‘long long unsigned int’}
Let's use our-own struct rseq copy fully equal to the kernel one,
it's safe because this structure is a part of Linux Kernel ABI.
Fixes#1934
Reported-by: Nikola Bojanic
Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>
Add a simple test using tail to check that processes can't be restored
by default when the r/w/x mode of an open file changes, unless
--skip-file-rwx-check is used.
Signed-off-by: Younes Manton <ymanton@ca.ibm.com>
A file's r/w/x changing between checkpoint and restore does
not necessarily imply that something is wrong. For example,
if a process opens a file having perms rw- for reading and
we change the perms to r--, the process can be restored and
will function as expected.
Therefore, this patch adds an option
--skip-file-rwx-check
to disable this check on restore. File validation is unaffected
and should still function as expected with respect to the content
of files.
Signed-off-by: Younes Manton <ymanton@ca.ibm.com>
stopped03 check that stopped by SIGTSTP tasks are restored correctly.
stopped04 check that stopped by SIGSTOP tasks which have blocked SIGTSTP and
have SIGTSTP pending are restored correctly.
Signed-off-by: Yuriy Vasiliev <yuriy.vasiliev@openvz.org>
Add SIGTSTP signal dump and restore. Add a corresponding field
in the image, save it only if a task is in the stopped state.
Restore task state by sending desired stop signal if it is present
in the image. Fallback to SIGSTOP if it's absent.
Signed-off-by: Yuriy Vasiliev <yuriy.vasiliev@openvz.org>
Currently, the content of anonymous private hugetlb mapping is dumped in 2
different images: memfd approach and normal private mapping dumping. In memfd
approach, we dump the content of the backing pseudo file (/anon_hugepage). This
is incorrect and redundant since the mapping is private, the content of backing
file may differ from the content of the mapping. With this commit, we remove the
redundant memfd approach dump and only do the normal private mapping dump on
anonymous hugetlb mapping.
Run zdtm.py run -f h --keep-img always -t zdtm/static/maps09, du -h in the
dumped image directory
Before this commit
13M test/dump/zdtm/static/maps09/55/1
After this commit
8.5M test/dump/zdtm/static/maps09/55/1
The reduction in size is approximately 4MB which is the size of anonymous
private hugetlb mapping in the test.
Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
