- 23 Nov, 2017 29 commits
-
-
Andrei Vagin authored
SO_REUSEPORT allows multiple sockets on the same host to bind to the same port. Signed-off-by:Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
Regs are present in unsigned format so convert them into signed first to provide results. In particular if memfd_create syscall failed we won't notice -ENOMEM error but rather treat it as unsigned hex value | (05.303002) Putting parasite blob into 0x7f1c6ffe0000->0xfffffff4 | (05.303234) Putting tsock into pid 42773 Signed-off-by:
Cyrill Gorcunov <gorcunov@virtuozzo.com> Reviewed-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Pavel Tikhomirov authored
Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
-
Pavel Tikhomirov authored
Signed-off-by:
-
Pavel Tikhomirov authored
In CT, we do: mkdir -p /a/b/c1 mkdir -p /c2 mount --bind /c2 /a/b/c1 mount --rbind /a/b /a And after that container is not dumpable with error: mnt: Unable to handle mounts under 146:./a Just because overmounts with shared parent group are prohibited, but I can't see any problem with enabling them. https://jira.sw.ru/browse/PSBM-69501Signed-off-by:
-
Pavel Tikhomirov authored
What we do before patch: 1) If we are NOT in the same shared group - if we have some parent's shared group member unmounted, we just wait for it. 2) If we are in the same group - we wait only for members with root path len shorter than ours. That is done to make child mount propagate in all shared group, but I think it is wrong, e.g.: mkdir -p /dir/a/b/c /d /e /f mount --bind /dir/a /d mount --bind /dir/a/b /e mount --bind /f /e/c Before c/r we have: 507 114 182:1017985 / / rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 144 507 182:1017985 /dir/a /d rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 146 507 182:1017985 /dir/a/b /e rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 148 146 182:1017985 /f /e/c rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 150 507 182:1017985 /f /dir/a/b/c rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 149 144 182:1017985 /f /d/b/c rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 After c/r we have: 600 132 182:1017985 / / rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 602 600 182:1017985 /f /dir/a/b/c rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 603 600 182:1017985 /dir/a /d rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 604 600 182:1017985 /dir/a/b /e rw,relatime shared:63 master:60 - ext4 /dev/ploop63624p1 rw,data=ordered,balloon_ino=12 There is no propagation as all mounts are in same shared group and 602(150) has shorter root than 603(144) and 604(146). What we should do: Wait member of our parent's shared group only if it has our 'sibling' mount in it. Sibling mount is the one which had propagated to shared mount of our parent for us when we were mounted. We need to enforce propagation only for these case. https://jira.sw.ru/browse/PSBM-69501Signed-off-by:
-
Cyrill Gorcunov authored
The anonymous shared memory are using shmid for image name encoding which is unsigned long and we already met scenario where high bits get strippped off thus the restore failed. Lets use unsigned long here, and because pagemap code is shared between plain memory and anon shared memory use unsigned long every where. Signed-off-by:
-
Cyrill Gorcunov authored
The index comes from mnt_id which is signed integer both in kernel and in userspace, but negative value is never valid, thus don't use it. Signed-off-by:
-
Cyrill Gorcunov authored
For images which are using pid as id for image names use unsigned format since here is no negative pid in real system. Signed-off-by:
-
Cyrill Gorcunov authored
It uses ns->id Signed-off-by:
-
Cyrill Gorcunov authored
Since it uses ns->id Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Just as we declare it in ns_id structure. Signed-off-by:
-
Cyrill Gorcunov authored
Same as for autofs. Signed-off-by:
-
Cyrill Gorcunov authored
Same as for autofs. Signed-off-by:
-
Cyrill Gorcunov authored
Both the kernel and criu uses unsigned int for it, make the format appropriate. | struct mount_info { | ... | unsigned int s_dev; | ... | } We didn't see negative number here in real life so I don't think if such %d to %u convention cause backward compatibility problem ever. Signed-off-by: -
Cyrill Gorcunov authored
We pass unsigned 4 byte integer here, so use appropriate format. Signed-off-by:
-
Cyrill Gorcunov authored
Namespace descriptors are not promised to have constant short names, so just to be on a safe side. Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
To test if we can survive with shmid more than 4 bytes long in image formats. Without the fix for shmid | [root@uranus criu] test/zdtm.py run -t zdtm/static/maps01 --fault 132 -f h -k always | === Run 1/1 ================ zdtm/static/maps01 | | ========================= Run zdtm/static/maps01 in h ========================== | Start test | Test is SUID | ./maps01 --pidfile=maps01.pid --outfile=maps01.out | Run criu dump | Forcing 132 fault | Run criu restore | Forcing 132 fault | =[log]=> dump/zdtm/static/maps01/36/1/restore.log | ------------------------ grep Error ------------------------ | (00.016464) 37: Opening 0x007f39c04b5000-0x007f3a004b5000 0000000000000000 (101) vma | (00.016465) 37: Search for 0x007f39c04b5000 shmem 0x10118e915 0x7f97f7ae4ae8/36 | (00.016470) 37: Waiting for the 10118e915 shmem to appear | (00.016479) 36: No pagemap-shmem-18409749.img image | (00.016481) 36: Error (criu/shmem.c:559): Can't restore shmem content | (00.016501) 36: Error (criu/mem.c:1208): `- Can't open vma | (00.016552) Error (criu/cr-restore.c:2449): Restoring FAILED. | ------------------------ ERROR OVER ------------------------ And with the fix | [root@uranus criu] test/zdtm.py run -t zdtm/static/maps01 --fault 132 -f h -k always | === Run 1/1 ================ zdtm/static/maps01 | | ========================= Run zdtm/static/maps01 in h ========================== | Start test | Test is SUID | ./maps01 --pidfile=maps01.pid --outfile=maps01.out | Run criu dump | Forcing 132 fault | Run criu restore | Forcing 132 fault | Send the 15 signal to 36 | Wait for zdtm/static/maps01(36) to die for 0.100000 | ========================= Test zdtm/static/maps01 PASS ========================= Signed-off-by:
-
Andrei Vagin authored
Signed-off-by: -
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 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:
-
- 21 Nov, 2017 11 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:
-
