Since commit cdd08cdff ("uffd: use userns_call() to execute
ioctl(UFFDIO_API)") UFFD_API ioctl() is wrapped with userns_call() and this
allows runing lazy-pages tests on recent kernels in uns.
Restore testing of lazy-pages in uns in travis.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
This commit adds ZDTM tests for c/r of processes with BPF maps as open
files
Source files added:
* zdtm/static/bpf_hash.c - Tests for c/r of the data and meta-data of
BPF map type BPF_MAP_TYPE_HASH
* zdtm/static/bpf_array.c - Tests for c/r of the data and meta-data
of BPF map type BPF_MAP_TYPE_ARRAY
Source files modified:
* zdtm/static/Makefile - Generating build artifacts for BPF tests
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit restores the data of BPF maps. A hash table (indexed by
the map's id) is used to store data objects for multiple BPF map
files that a process may have opened. Collisions are resolved with
chaining using a linked list.
Source files modified:
* bpfmap.c - Structure and function definitions needed to:
(a) collect the protobuf image containing BPF map data
(b) read the BPF map's data from the image and store it in the
hash table
(c) restore the map's data using bpf_map_update_batch()
* include/bpfmap.h
- Defines the size of the hash table and maks to be used while
indexing into it
- Structure and function declarations that are used while restoring
BPF map data
* cr-restore.c - Collects the protobuf image containing BPF map data
during the restoration phase
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit enables CRIU to restore a process' BPF map file
descriptors.
Source files modified:
* bpfmap.c - Structure and function definitions needed to:
(a) collect a BPF map's information from its protobuf image
(b) create and open a BPF map with the same parameters as when
it was dumped
(c) add the newly opened BPF map to the process' file descriptor
list
* include/bpfmap.h - Structure declarations for restoring BPF maps
* files.c - Collects a BPF map's file entry during the restoration
phase
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit enables CRIT to decode the contents of a protobuf image
that stores information related to BPF map
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit enables CRIU to dump data(key-value) pairs stored in BPF
maps
Source files modified:
* bpfmap.c
- Function dump_one_bpfmap_data() reads the map's keys and
values into two buffers using bpf_map_lookup_batch() and then
writes them out to a protobuf image along with the number of
key-value pairs read
- Function dump_one_bpfmap() now dumps the data as well before
returning
* include/bpfmap.h - Includes headers and declares functions needed to
dump BPF map data
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit enables CRIU to dump meta-data about BPF maps files by
prividing the structures and functions needed by other parts of the
code-base.
Source files added:
* bpfmap.c - defines new structures and functions:
(a) struct fdtype_ops bpfmap_dump_ops:
sets up the function handler to dump BPF maps
(b) is_bpfmap_link():
checks whether an anonymous inode is a BPF map file
(c) dump_one_bpfmap():
parses information for a BPF map file from procfs and
dumps it
* include/bpfmap.h - structure and function declarations
Source files modified:
* Makefile.crtools - generates build artifacts for bpfmap.c
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit enables CRIU to:
(a) identify an anonymous inode as being a BPF map
(b) parse information about BPF maps from procfs
Source files modified:
* files.c - Checks anonymous inodes to see whether they are BPF maps.
If so, sets struct fdtype_ops *ops to a structure that knows how to
dump BPF maps
* proc_parse.c - Function parse_fdinfo_pid_s() now checks whether the
current file being processed is a BPF map. If so, it calls a newly
defined function parse_bpfmap() which knows how to parse information
about BPF maps from procfs
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
Source files modified:
* Makefile.config - Checks whether libbpf is installed on the system.
If so, we add -lbpf to LIBS_FEATURES, -DCONFIG_HAS_LIBBPF to
FEATURE_DEFINES and set CONFIG_HAS_LIBBPF. This allows us to check for
the presence of libbpf before compiling or executing BPF c/r code and
ZDTM tests.
* Makefile - Set CONFIG_HAS_LIBBPF to clean all files.
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit defines constants and includes necessary headers to c/r
BPF maps
Source files modified:
* magic.h - Defining BPFMAP_FILE_MAGIC and BPFMAP_DATA_MAGIC
* image-desc.h - Defining CR_FD_BPFMAP_FILE and CR_FD_BPFMAP_DATA
* image-desc.c - Create new entries for bpfmap-file and bpfmap-data
in CRIU's file descriptor set
* protobuf-desc.h - Defining PB_BPFMAP_FILE and PB_BPFMAP_DATA
* protobuf-desc.c - Including headers for BPF map protobuf images
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
This commit adds protobuf definitions needed to checkpoint and
restore BPF map files along with the data they contain
Source files added:
* bpfmap-file.proto - Stores the meta-data about BPF maps
* bpfmap-data.proto - Stores the data (key-value pairs) contained
in BPF maps
Source files modified:
* fdinfo.proto - Added BPF map as a new kind of file descriptor.
'message file_entry' can now hold information about BPF map file
descriptors
* Makefile - Now generates build artifacts for bpfmap-file.proto
and bpfmap-data.proto
Signed-off-by: Abhishek Vijeev <abhishek.vijeev@gmail.com>
Master branch does not have mips support yet, so automated builds for
mips on the master branch fail.
Temporarily split mips cross-build into a separate files until mips
support will be mergded into the master branch.
Suggested-by: Adrian Reber <areber@redhat.com>
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
This adds a definition to do a daily rebuild of all cross-compile tests
on the master and criu-dev branch.
Signed-off-by: Adrian Reber <areber@redhat.com>
One of the most common CI errors we see is that package install fails
due to some hashsum mismatch or some DNS errors.
This adds a loop around each apt-get install call to do a clean, update
and install and if one of the steps fails it repeats it up to 10 times.
Signed-off-by: Adrian Reber <areber@redhat.com>
I always wondered why re-running make on a criu checkout always prints
out
GEN magic.py
even if no file has changed. It seems the Makefile was looking for the
file in the wrong location. Providing the full path to the file will now
only rebuild magic.py if something actually changed that requires a
rebuild.
Signed-off-by: Adrian Reber <areber@redhat.com>
Fixes#1165
Traceback (most recent call last):
File "../criu/crit/crit-python3", line 6, in <module>
cli.main()
File "/home/xcv/repos/criu/crit/pycriu/cli.py", line 410, in main
opts["func"](opts)
File "/home/xcv/repos/criu/crit/pycriu/cli.py", line 43, in decode
json.dump(img, f, indent=indent)
File "/usr/lib/python3.8/json/__init__.py", line 179, in dump
for chunk in iterable:
File "/usr/lib/python3.8/json/encoder.py", line 431, in _iterencode
yield from _iterencode_dict(o, _current_indent_level)
File "/usr/lib/python3.8/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/lib/python3.8/json/encoder.py", line 325, in _iterencode_list
yield from chunks
File "/usr/lib/python3.8/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/lib/python3.8/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/lib/python3.8/json/encoder.py", line 438, in _iterencode
o = _default(o)
File "/usr/lib/python3.8/json/encoder.py", line 179, in default
raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type bytes is not JSON serializable
Co-authored-by: Julian <jb@futureplay.de>
Signed-off-by: Otto Bittner <otto-bittner@gmx.de>
The description of the Fixes: tags could be misleading and may be
understood as if "Fixes: " should be the commit summary.
Add a sentence with explicit description of Fixme: tags placement.
Reported-by: Otto Bittner <otto-bittner@gmx.de>
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
When using libcriu with the notify callback functionality CRIU transmits
an FD during 'orphan-pts-master' back to libcriu user. This is message
is sent via sendmsg() to transmit the FD and not via write() as all
other protobuf messages.
libcriu was using recv() and to be able to receive the FD this needs to
be changed to recvmsg() and if an FD is attached to it (currently only
for 'orphan-pts-master' this FD is stored in a variable which can be
retrieved with the function criu_get_orphan_pts_master_fd().
Signed-off-by: Adrian Reber <areber@redhat.com>
The decision whether a log message is info/warning/error should
be made by the place in code where it's shown, not by any other
expression. This makes it pointless to use the print_on_level
directly, as in each particular place the needed pr_foo() helper
can be chosen.
However, we cannot (easily) make this function static, so keep
it in header, but ask people to think twise (or more times) before
calling it directly.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
If a helper routine doesn't know whether its failure leads
to the error, then it should just emit a warning and return
-1. It's the caller who should print (or not) the error.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Instead of directly calling the print_on_level.
The pr_msg/pr_warn seems to be better choise for all those cases.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
This addresses a bug where the RegFileEntry n_build_id field would be
populated with incorrect data, causing dump to crash at times.
Signed-off-by: Ajay Bharadwaj <ajayrbharadwaj@gmail.com>
This addresses a bug when the ELF file contains multiple PT_NOTE program
headers but only the first header is checked for the build-id.
Signed-off-by: Ajay Bharadwaj <ajayrbharadwaj@gmail.com>
Previously, the GOT table was using the same memory location as the
args region, leading to difficult to debug memory corruption bugs.
We allocate the GOT table between the parasite blob and the args region.
The reason this is a good placement is:
1) Putting it after the args region is possible but a bit combersome as
the args region has a variable size
2) The cr-restore.c code maps the parasite code without the args region,
as it does not do RPC.
Another option is to rely on the linker to generate a GOT section, but I
failed to do so despite my best attempts.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
We don't need to push 0 on the stack. This seems to be a remnant of the
initial commit of 2011 that had a `pushq $0`.
The 16 bytes %rsp alignment was added with commit 2a0cea29 in 2012.
This is no longer necessary as we already guarantee that %rsp is 16
bytes aligned. A BUG_ON() is added to enforce this guarantee.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
Previously, __export_parasite_cmd was located in parasite-head.S, and
__export_parasite_args located exactly at the end of the parasite blob.
This is not ideal for various reasons:
1) These two variables work together. It would be preferrable to have
them in the same location
2) This prevent us from allocating another section betweeen the parasite
blob and the args area. We'll need this to allocate a GOT table
This commit changes the allocation of these symbols from assembly/linker
script to a C file.
Moreover, the assembly entry points that invoke parasite_service()
prepares arguments with hand crafted assembly. This is unecessary.
This commit rewrite this logic with regular C code.
Note: if it wasn't for the x86 compat mode, we could remove all
parasite-head.S files and directly jump to parasite_service() via
ptrace. An int3 architecture specific equivalent could be called at the
end of parasite_service() with an inline asm statement.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
It is unnecessary and potentially confusing for understanding the memory
layout requirement of the parasite blob.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
It removes the potential confusion when it comes to virtual address vs
offsets. Further, doing so makes naming more consistent with the rest of
the parasite_blob_desc struct.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
compel_relocs_apply() was taking arguments mostly from the struct
parasite_blob_desc. Instead of passing all the arguments, we pass a
pointer to the struct itself.
This makes the code safer, as cr-restore.c calls compel_relocs_apply().
It previously needed to poke into what can be considered private
variables of the restorer-pie.h file.
To allow the parasite_blob_desc struct to be populated without a
parasite_ctl struct, we expand the compel API to export a
parasite_setup_c_header_desc() in the generated pie.h.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
COMMON symbols are emitted for global variable that are not initialized
in shared libraries.
They typically end up in the .bss section when linking an executable.
Signed-off-by: Nicolas Viennot <Nicolas.Viennot@twosigma.com>
This change is very straightforward. We don't skip the cgroup2
controller and dump it as any other controllers.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
I pushed the wrong branch to the pidns PR
https://github.com/checkpoint-restore/criu/pull/1056
which resulted in the wrong patches getting merged.
This is the actual result from the review.
Signed-off-by: Adrian Reber <areber@redhat.com>
file_validation_method field added to cr_options structure in
"criu/include/cr_options.h" along with the constants:
FILE_VALIDATION_FILE_SIZE
FILE_VALIDATION_BUILD_ID
FILE_VALIDATION_DEFAULT (Equal to FILE_VALIDATION_BUILD_ID)
Usage and description information is yet to be added
Usage:
--file-validation="filesize" (To use only the file size check)
--file-validation="buildid" (To try and use only the build-id check)
Signed-off-by: Ajay Bharadwaj <ajayrbharadwaj@gmail.com>
efi.h: Required for accessing the build-id of .efi files
This adds functions to find, store and compare with the stored build-id.
get_build_id() calls 32-bit or 64-bit helper functions depending on
the bitness of the ELF file after first ensuring that it is actually
an ELF file by checking for the magic number.
The number of iterations while searching the elf file for the
build-id before giving up (500 while searching the note section)
are limited.
Signed-off-by: Ajay Bharadwaj <ajayrbharadwaj@gmail.com>
