[CRIU] [PATCH 0/2] BPF map files are now dumped.
Abhishek Vijeev
abhishek.vijeev at gmail.com
Tue Apr 21 22:27:39 MSK 2020
Hi,
With reference to https://github.com/checkpoint-restore/criu/issues/777 and
https://lists.openvz.org/pipermail/criu/2020-April/044957.html, I have modified the function
'parse_fdinfo_pid_s()' to parse BPF file info from the proc filesystem.
A small note: I have changed the labels of 3 fields of bpfmap-file.proto to 'required' in order
to verify whether all fields were being dumped successfully ('optional' fields were not dumped by
CRIU and hence the change). As mentioned in point (b) of my previous email, I will correctly label
all fields of the bpfmap-file.proto file with the right datatypes too, once I better understand
the nature of data stored in the proc filesystem for BPF maps.
For the example program here https://github.com/checkpoint-restore/criu/issues/777#issue-490673307,
CRIU now dumps the BPF map file information as shown below.
Here the output of the dump 'files.img' obtained using 'crit show':
{
"magic": "FILES",
"entries": [
{
"type": "REG",
"id": 1,
"reg": {
"id": 1,
"flags": "",
"pos": 0,
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"name": "/home/abhishek/criu_dumps/bpf_test",
"size": 8472,
"mode": 33277
}
},
{
"type": "REG",
"id": 2,
"reg": {
"id": 2,
"flags": "",
"pos": 0,
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"name": "/lib/x86_64-linux-gnu/libc-2.27.so",
"size": 2030544,
"mode": 33261
}
},
{
"type": "REG",
"id": 3,
"reg": {
"id": 3,
"flags": "",
"pos": 0,
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"name": "/lib/x86_64-linux-gnu/ld-2.27.so",
"size": 170960,
"mode": 33261
}
},
{
"type": "REG",
"id": 5,
"reg": {
"id": 5,
"flags": "O_RDWR",
"pos": 0,
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"name": "/dev/pts/2",
"mode": 8576
}
},
{
"type": "TTY",
"id": 4,
"tty": {
"id": 4,
"tty_info_id": 4,
"flags": "0x2",
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"regf_id": 5
}
},
{
"type": "BPFMAP",
"id": 6,
"bpf": {
"id": 6,
"flags": "O_RDWR",
"pos": 0,
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"map_type": 3,
"key_size": 4,
"value_size": 4,
"map_id": 13,
"max_entries": 4
}
},
{
"type": "REG",
"id": 7,
"reg": {
"id": 7,
"flags": "",
"pos": 0,
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"name": "/home/abhishek/criu_dumps",
"mode": 16893
}
},
{
"type": "REG",
"id": 8,
"reg": {
"id": 8,
"flags": "",
"pos": 0,
"fown": {
"uid": 0,
"euid": 0,
"signum": 0,
"pid_type": 0,
"pid": 0
},
"name": "/",
"mode": 16877
}
}
]
}
Here the output of the dump 'fdinfo-2.img' obtained using 'crit show':
{
"magic": "FDINFO",
"entries": [
{
"id": 4,
"flags": 0,
"type": "TTY",
"fd": 0
},
{
"id": 4,
"flags": 0,
"type": "TTY",
"fd": 1
},
{
"id": 4,
"flags": 0,
"type": "TTY",
"fd": 2
},
{
"id": 6,
"flags": 1,
"type": "BPFMAP",
"fd": 3
}
]
}
I apologize for the multiple patche submissions, as I over-estimated the time required to
code up the parsing part.
I await your kind feedback. In the meanwhile, I shall start working on restoring BPF map files.
Thank you,
Abhishek Vijeev.
Abhishek Vijeev (2):
Preliminary set of changes to support dumping BPF map files. A major
task is yet to be completed: parsing BPF file info from the proc
filesystem in the function parse_fdinfo_pid_s()
BPF map files are now dumped. Also changed the labels of 3 fields of
bpfmap-file.proto to 'required' in order to verify whether all
fields are being dumped.
criu/Makefile.crtools | 1 +
criu/bpfmap.c | 49 ++++++++++++++++++++++++
criu/files.c | 5 +++
criu/include/bpfmap.h | 9 +++++
criu/proc_parse.c | 81 ++++++++++++++++++++++++++++++++++++++++
images/Makefile | 1 +
images/bpfmap-file.proto | 23 ++++++++++++
images/fdinfo.proto | 4 ++
8 files changed, 173 insertions(+)
create mode 100644 criu/bpfmap.c
create mode 100644 criu/include/bpfmap.h
create mode 100644 images/bpfmap-file.proto
--
2.17.1
More information about the CRIU
mailing list