- 23 Nov, 2017 3 commits
-
-
Kirill Tkhai authored
Reflect commit 3086b0323cf8 "pstree: Dump and restore NSpid, NSsid etc" in crit. Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
flake8 was updated recently and now it shows a few new warnings: [root@fc24 criu]# make lint flake8 --config=scripts/flake8.cfg test/zdtm.py test/zdtm.py:181:4: E722 do not use bare except' test/zdtm.py:304:2: E722 do not use bare except' test/zdtm.py:325:3: E722 do not use bare except' test/zdtm.py:445:3: E722 do not use bare except' test/zdtm.py:573:4: E722 do not use bare except' test/zdtm.py:1369:2: E722 do not use bare except' test/zdtm.py:1385:3: E722 do not use bare except' test/zdtm.py:1396:2: E722 do not use bare except' test/zdtm.py:1420:3: E722 do not use bare except' test/zdtm.py:1820:2: E741 ambiguous variable name 'l' make: *** [Makefile:369: lint] Error 1 Signed-off-by: -
Cyrill Gorcunov authored
https://github.com/checkpoint-restore/criu/issues/399Rerorted-by:
Andrew Vagin <avagin@openvz.org> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
- 21 Nov, 2017 16 commits
-
-
Cyrill Gorcunov authored
Also use task_waiter_t syncpoint to make sure fd won't escape while we're reading output. Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Andrei Vagin authored
All Jenkins jobs fail with this error: 22:25:13.186: 37: ERR: cgroup_ifpriomap.c:50: Can't mount cgroups (errno = 16 (Device or resource busy)) Signed-off-by: -
Dmitry Safonov authored
A test to check C/R of multiline cgroup net_prio.ifpriomap. Before this patches set restoring of this file failed as it's a multiline cgroup property and kernel can read it only line-by-line. Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
-
Dmitry Safonov authored
Those are devices which are written to devices.allow cgroup. Signed-off-by:
-
Dmitry Safonov authored
Skip writing 0 for interfaces, as it's the default value. Signed-off-by:
-
Dmitry Safonov authored
net_prio.ifpriomap property may differ between hosts as they may have different number of interfaces and this cgroup property property has init-ns interfaces, not net-ns: https://www.spinics.net/lists/netdev/msg418785.html Let's skip fails if interface is no longer present on restore. Signed-off-by:
-
Dmitry Safonov authored
At this moment the kernel doesn't support multi-line write() to net_prio.ifpriomap. On such write the kernel will parse only the first line. That results in the following failed restore: > (01.454153) cg: Restoring cgroup property value [lo 0 > enp5s0 0 > enp6s0 0 > br0 0 > venet0 0 > host-routed 0 > virbr0 0 > virbr0-nic 0] to [net_prio,net_cls/machine.slice/91d3ac46-380e-4d91-89d3-d2bd1eb30f97/net_prio.ifpriomap] > (01.454188) Error (criu/cgroup.c:1225): cg: Failed writing lo 0 > enp5s0 0 > enp6s0 0 > br0 0 > venet0 0 > host-routed 0 > virbr0 0 > virbr0-nic 0 to net_prio,net_cls/machine.slice/91d3ac46-380e-4d91-89d3-d2bd1eb30f97/net_prio.ifpriomap: Argument list too long > (01.472144) Error (criu/cr-restore.c:1013): 20509 killed by signal 9: Killed > (01.472391) mnt: Switching to new ns to clean ghosts > (01.472690) Error (criu/cr-restore.c:2007): Restoring FAILED. Signed-off-by:
-
Dmitry Safonov authored
As for-cycle already checks it. While at it - add local CgroupPropEntry variable and use it. Signed-off-by:
-
Dmitry Safonov authored
We need to write some multiline properties line-by-line, instead of writing all buffer at once - because kernel doesn't support parsing them in one write(). Previously, it was done for devices.allow list, but I need it also for netprio.ifpriomap. To make easier reusing this code, add split_lines parameter to restore_cgroup_prop(). Dropping next_device_entry() and multiply calls to restore_cgroup_prop() also improves performance: previously for each property's line, cgroup file was re-open() and close() again, while new code only calls write() for each line, reducing number of syscalls done for each line. This also makes it suitable for future: if patch(s) for parsing all lines of property with one write() would be accepted, then we can easily change call to something: restore_cgroup_prop(&dev_allow, paux, off, !kdat.cgroup_multiline_write); We can even use split_lines = true by default for all cases, as strchrnul() will only find zero-terminator as does strlen(). But I don't want to do it - if there are cgroup files which supportes multi-line write(), it'll add syscalls. Signed-off-by:
-
Dmitry Safonov authored
Now restore_special_property() only deals which special property restore and restore_devices_list() deals with devices.list. BTW, let's have two variables dev_allow and dev_deny on stack to simplify it - all this fuss with old_val and old_name kills the fun. Signed-off-by:
-
Dmitry Safonov authored
To reduce restore_special_props() size - let's factor a new function for restoring one special property. No functional change expected. Signed-off-by:
-
Dmitry Safonov authored
For the purpose of separation this as a function, refactor the code to use local variable prop, so the new function will have (CgroupPropEntry *) type instead of (CgroupDirEntry *). Signed-off-by:
-
Dmitry Safonov authored
Let's add a function which will tell if cgroup property is special. Note that I do not touch restore_special_props() indention in this patch as I separate subfunction from it in the next patch, so touching this pile of code once. Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
-
- 23 Oct, 2017 1 commit
-
-
Pavel Emelyanov authored
As usually -- many bugfixes and several new features. The s390x stuff goes well too. The most tempting new feature is the ability to dump and restore files sent over unix sockets (SCM_RIGHTS). Signed-off-by:
-
- 22 Oct, 2017 5 commits
-
-
Andrei Vagin authored
Signed-off-by: -
Andrei Vagin authored
Its declaration was changed in glibc headers and we don't want to handle two version of itю In file included from compel/include/uapi/compel/infect.h:6:0, from compel/include/uapi/compel/compel.h:12, from compel/include/log.h:4, from compel/arch/aarch64/src/lib/infect.c:8: compel/arch/aarch64/src/lib/infect.c: In function 'sigreturn_prep_regs_plain': compel/include/uapi/compel/asm/sigframe.h:47:99: error: 'mcontext_t {aka struct <anonymous>}' has no member named '__reserved'; did you mean '__glibc_reserved1'? #define RT_SIGFRAME_AUX_CONTEXT(rt_sigframe) ((struct aux_context*)&(rt_sigframe)->uc.uc_mcontext.__reserved) ^ compel/include/uapi/compel/asm/sigframe.h:48:41: note: in expansion of macro 'RT_SIGFRAME_AUX_CONTEXT' #define RT_SIGFRAME_FPU(rt_sigframe) (&RT_SIGFRAME_AUX_CONTEXT(rt_sigframe)->fpsimd) ^~~~~~~~~~~~~~~~~~~~~~~ compel/arch/aarch64/src/lib/infect.c:34:34: note: in expansion of macro 'RT_SIGFRAME_FPU' struct fpsimd_context *fpsimd = RT_SIGFRAME_FPU(sigframe); ^~~~~~~~~~~~~~~ make[1]: *** [/builddir/build/BUILD/criu-3.5/scripts/nmk/scripts/build.mk:209: compel/arch/aarch64/src/lib/infect.o] Error 1 make: *** [Makefile.compel:36: compel/libcompel.a] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.IExY9K (%build) This seems to be related to the following glibc changes: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4fa9b3bfe6759c82beb4b043a54a3598ca467289Reported-by:Adrian Reber <adrian@lisas.de> Tested-by:
-
Dmitry Safonov authored
Add handeling of R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. They are not that old, so I provided ifdef-guards for them. According to x86-64 ABI specification paper, they should be generated instead of R_X86_64_GOTPCREL for cases when relaxation is possible. At this moment we can handle them the same way like R_X86_64_GOTPCREL. [0] https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf Fixes: #397 Cc: Cyrill Gorcunov <gorcunov@openvz.org> Reported-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
-
Andrei Vagin authored
p + FAST_SIZE > buffer + length In this sentence p + FAST_SIZE may be bigger than (1<<32), and we will be in trouble. $ gdb -c coredump test/zdtm/static/write_read01 (gdb) p p $3 = (uint8_t *) 0xffffa89e (gdb) p buffer $4 = (uint8_t *) 0xfff06780 (gdb) p length $5 = 1000000 Signed-off-by: -
Mike Rapoport authored
The lazy-thp may fail with older kernels if khugepaded will be fast enough to merge pages in the partially populated areas. Signed-off-by:
-
- 17 Oct, 2017 15 commits
-
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
The CMSG_NXTHDR checks the length of the __next__ cmsg, i.e. the one that it is about to return for filling. Thus, keeping there anything but zeroes is unsafe. Reported-by:
Pavel Tikhomirov <snorcht@gmail.com> Signed-off-by:
-
Pavel Emelyanov authored
Most of the pieces has already been described in the previous patches :) so here's the summary. * Dump: When receiving a message, also receive any SCM-s (already there) and when SCM_RIGHTs one is met -- go ahead and just dump received descriptors using regular code, but taking current as the victim task. Few words about file paths resolution -- since we do dump path-ed files by receiving them from victim's parasite, such files sent via sockets should still work OK, as we still receive them, just from another socket. Several problems here: 1. Unix sockets sent via unix sockets form knots. Not supported. 2. Eventpolls sent via unix might themseves poll unix sockets. Knots again. Not supported either. * Restore: On restore we need to make unix socket wait for the soon-to-be-scm-sent descriptors to get restored, so we need to find them, then put a dependency. After that, the fake fdinfo entry is attached to the respective file descs, when sent the respective descriptors are closed. https://github.com/xemul/criu/issues/251 v2: Addressed comments from Kirill * Moved prepare_scms before adding fake fles (with comment) * Add scm-only fles as fake, thus removing close_scm_fds * Try hard finding any suitable fle to use as scm one when queuing them for unix socket scm list, only allocate a new one if really needed Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
Reviewed-by:
-
Pavel Emelyanov authored
In order to make sender of a descriptor (unix socket) be restored _after_ the descriptor in question, we need to find out those sockets early (before post-prep calls). The problem is that current code gives us info about who's the queuer for who only in post-prep hooks, so the peer resolution should happen right in collect callback. At the same time we need to make sure that all peers configured in the image exist, as well as need to put master/slave flags for socketpairs. Both these actions can only happen in post-prep. Said that -- the current peer resolve routine should be split into two steps. v2: Handle the socket connected to self (dgram) Reviewed-by:
-
Pavel Emelyanov authored
The sk-queue.img keeps socket IDs as recepient descriptor. For SCM code we'll need to find the unix sk info who is the sender for a particular other socket by this ID. There's already the queuer field in the unix_sk_info, but it needs to be an ID rather than inode. Fortunately, id-inode pairs are unique. Reviewed-by:
-
Pavel Emelyanov authored
For SCM restore we need to know all queuers, even if they are socketpair-s, but current code skips this setting for one half of them. So set this info for every socket out there. Reviewed-by:
-
Pavel Emelyanov authored
In SCM code there will be the need to attach a newly created FdinfoEntry to a particulat file desc object, then get the created fdinfo helper object back. Current code only allows this via two lookup calls -- first one to attach entry to desc by ID (lookup #1), then get the fdinfo helper by FD (lookup #2). Fortunately, the exising code allows simple split that gives us the optimized routine. Reviewed-by:
-
Pavel Emelyanov authored
In SCM patch we'll need to generate temporary fdinfo entry for a task that will send descriptors via sockets. Sometimes the files in questions will NOT have any other fdinfo-s (if they are SCM-sent and closed), so we need a helper that would either give us existing fdinfo or say there's no such. Reviewed-by:
-
Pavel Emelyanov authored
An aux code to dump the received file and report back its ID and type. Reviewed-by:
-
Pavel Emelyanov authored
Actually all file-s we dump have unique IDs, regardless of their types. This fact will be used to reduce complexity of the SCM code -- instead of keeping TYPE:ID pair it'll save only the ID. Siad that -- we will need the way to lookup desc by ID only. v2: Older images had fifo-s and tty-s having matching IDs with respective reg-file entries Reviewed-by: -
Pavel Emelyanov authored
To support SCMs we'll need to receive them into criu task (see the SCM patch for details), then dump the received file as if it was in the dumpee. Then the info about received descriptor will be written into packet entry. For this we'll need to perform all the regular file dumping code BUT not write the FdinfoEntry into image, so shuffle the code for that. The gist of the patch is in two changes -- one in the do_dump_gen_file(), the other in dump_task_files_seized(). The rest is just tossing the arguments of the functions relevant to that change. Reviewed-by:
-
Pavel Emelyanov authored
Same thing as for fifo-s. Reviewed-by:
-
Pavel Emelyanov authored
The plan is to have all file entries have unique ID. Fifo generates a reg file entry to reuse the whole reg-files c/r-ing engine (ghosts, open-by-path, etc.) and right now ID for this entry is the same as for fifo entry. Reviewed-by:
-
