- 30 May, 2016 9 commits
-
-
Dmitry Safonov authored
This should fix errors on build envs, where git tags haven't been fetched. I.e, Travis-ci does not fetch tags before building a project, wich results in: ---> Running in 0d63a3d28a7a fatal: No names found, cannot describe anything. fatal: No names found, cannot describe anything. make[1]: Entering directory '/criu' The other way is to fetch tags on `git describe` failure, but it that way has two cons: - it will change user's git (and I'm not sure it's right); - we need not only fetch tags in that case, but also remotes, as otherwise it will fail with "fatal: No tags can describe <hash>": https://travis-ci.org/0x7f454c46/criu/jobs/133362045#L1748 Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
-
Pavel Tikhomirov authored
to fix error: ./crit/crit decode -i test/dump/zdtm/static/maps04/118/1/stats-dump Traceback (most recent call last): File "./crit/crit", line 276, in <module> main() File "./crit/crit", line 273, in main opts["func"](opts) File "./crit/crit", line 28, in decode img = pycriu.images.load(inf(opts), opts['pretty'], opts['nopl']) KeyError: 'nopl' Signed-off-by:Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
-
Pavel Emelyanov authored
In some images there can be quite a long "payload" -- some raw data that is represented by base64 encoding. If we want to explore huge images reading tons of base64 symbols can be quite time consuming :) E.g. I a 1.5 gigs image with sysv shmem was sent to me some time ago for investigation %) So here is the --nopl argument for show action (decode should produce encode-able image, so payload there is needed) that just shows the amount of bytes in payload (if any). Signed-off-by: -
Dmitry Safonov authored
This seems to be known problem in util-vdso.c on aarch64 [1]. Now restorer segfaults with the following log: [ 8107.384817] criu[5135]: unhandled level 3 translation fault (11) at 0x00005b98, esr 0x90000007 [ 8107.385538] pgd = ffffffc038dbc000 [ 8107.386046] [00005b98] *pgd=0000000078d6c003, *pud=0000000078d6c003, *pmd=0000000073c31003, *pte=0000000000000000 [ 8107.391920] [ 8107.392521] CPU: 0 PID: 5135 Comm: criu Not tainted 4.5.0 #29 [ 8107.392805] Hardware name: linux,dummy-virt (DT) [ 8107.393140] task: ffffffc039a2a400 ti: ffffffc033c34000 task.ti: ffffffc033c34000 [ 8107.393782] PC is at 0x13514 [ 8107.406332] LR is at 0x1342c [ 8107.406550] pc : [<0000000000013514>] lr : [<000000000001342c>] pstate: a0000000 This is because gcc for aarch64 adds vdso_symbols array to symbols table and by that reason, it needs run-time relocations in place. How it goes (with cut not interesting assembly): 0x14104: adrp x7, 0x14000 ; adrp+add loading of 0x14114: add x0, x7, #0x928 ; symbol table's address, 0x14134: ldp x2, x3, [x0] ; loading address of symbol from ; symbol table 0x1414c: stp x2, x3, [x29,#112] ; saving it on stack on ; function's begin 0x14188: ldr x2, [x29,#112] ; using symbol's address in code The symbol for this in symbol table is: [root@alarm cr]# readelf -s criu/pie/restorer.built-in.bin.o | grep 5b98 248: 0000000000005b98 0 NOTYPE LOCAL DEFAULT 1 $d And also may be visible this way: objdump -dS criu/pie/restorer.built-in.bin.o | less ... 0000000000004924 <cur_loglevel>: 4924: 00000002 00005b98 00000000 00005ed0 .....[.......^.. 4934: 00000000 00005ee8 00000000 00005f00 .....^......._.. So, in a symbol table lies not relocated address of symbol. The real address may be visible with added printing of vdso_symbols[0]: pie: vdso: vdso_symbols[0] 0x15b98 (this way gcc by some reason does access symbol through local adrp+add calculations, than through stack-saved pointer of a symbol from symbol table). While we don't handling properly relocs here, I suggest this ugly workaround. Temporary fix for: #150 [1]: https://lists.openvz.org/pipermail/criu/2015-October/022453.html Cc: Wang Long <long.wanglong@huawei.com> Cc: Christopher Covington <cov@codeaurora.org> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:long.wanglong <long.wanglong@huawei.com> Signed-off-by:
-
Dmitry Safonov authored
As for compatible 32-bit pie size of uint64_t is bigger than size of unsigned long type, add proper casts, so we could build compatible pie. Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
We are going to build everything from toplevel for convenience (just like it was before criu 2) so move one more snippet on top. Signed-off-by:
-
Cyrill Gorcunov authored
They are already defined and exported. Signed-off-by:
-
Cyrill Gorcunov authored
We use in our PCS7 packaging and I think it's suitable for everything else as well. Signed-off-by:
-
- 27 May, 2016 31 commits
-
-
Pavel Emelyanov authored
Signed-off-by: -
Andrew Vagin authored
Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
-
Andrew Vagin authored
$ git log v4.4-rc1-465-gd6df198 commit d6df198d924775e4751561cf60ef0294e95f74df Author: Phil Sutter <phil@nwl.cc> Date: Tue Dec 1 22:45:15 2015 +0100 net: ipv6: restrict hop_limit sysctl setting to range [1; 255] Setting a value bigger than 255 resulted in using only the lower eight bits of that value as it is assigned to the u8 header field. To avoid this unexpected result, reject such values. https://github.com/xemul/criu/issues/164Signed-off-by: -
Andrew Vagin authored
shmem.c:290:4: note: in expansion of macro 'pr_err' pr_err("Shmem %lx already collected as SYSVIPC\n", vi->shmid); ^ v2: fix one more place Signed-off-by: -
Andrew Vagin authored
====================== Run zdtm/static/mnt_tracefs in uns ====================== Start test ./mnt_tracefs --pidfile=mnt_tracefs.pid --outfile=mnt_tracefs.out --dirname=mnt_tracefs.test Run criu dump Wait for zdtm/static/mnt_tracefs to die for 0.100000 Run criu restore Run criu dump Run criu restore Run criu dump Run criu restore 1: Old mounts lost: set([]) 1: New mounts appeared: set([('/', '/debugfs/tracing')]) Wait for zdtm/static/mnt_tracefs to die for 0.100000 Cc: Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by:Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
All the dumping code sits in there, so it's time to move the restoring one there too :) Signed-off-by: -
Pavel Emelyanov authored
We have 3 structures and 2 ways to keep them while doing C/R. Let's unify the vma_area is -- one struct with union and a hash table. Signed-off-by: -
Pavel Emelyanov authored
We now have two places where we if/elseif/elseif/else a vma and take actions -- the prepare_mm_pid and open_vmas. I propose to make this if/... onlce once (while preparing) and set up a callback on vma to be called later (while opening). This requires my patch that doesn't set -1 in alloc_vma or Andrey's patch that does the same. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Image a process has done shmget(2 pages), then shmat() then mprotect(1 page, ro). In this case criu will dump 1 shmem segment 2 pages long and 2 vmas 1 page each. But on restore time we'll call shmat() for _each_ vma and the very first one will occupy the whole 2 pages space in vm (there's no size argument for shmat, only for shmget) thus blocking the 2nd vma from shmat()-in again. The solution is: 1. check that each shmem segment is attached by the sequence of vmas that cover one w/o holes 2. shmat() only the first one 3. mprotect() all of them if needed (there's no hunks for this step in this path, mprotect is already called in pie/restorer.c and does things well) v2: * List can contain anon shmems (caught by zdtm) * There can be many attachments of a segment (caught by transition/ipc) Signed-off-by: -
Cyrill Gorcunov authored
When testing for queued data present on peers we setup non-blocking mode over them to obtain -EAGAIN if there is no data at all, but I forget to restore former mode on return, ie blocking read. Reported-by:
-
Cyrill Gorcunov authored
For easier reading: we need it for pty queued data only, but this way the code is simplier. Signed-off-by:
-
Andrey Ryabinin authored
Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by:
-
Andrey Ryabinin authored
Usually unix stream sockets have consistent shutdown state (if one end shutdown for read than other end will be shut down for write). However sometimes it's possible to have stream sockets with mismatched shutdown state. This happens if we connect() already shut down socket (see upcoming sockets03.c test for example). On read()/write() kernel always checks shutdown state on both ends, so from userspace POV sockets with mismatched shutdown state behave the same way as with matched state. So I think that we can just ignore shutdown mismatch during dump, and just restore sockets with matching shutdown state. Process should not see the differences. Signed-off-by:
-
Tycho Andersen authored
The inital mount() call for a bind mount needs to have the MS_REC flag present if the bind mount is recursive. Signed-off-by:
-
Pavel Tikhomirov authored
Sting field sysctl_entry.sarg has wrong length in protobuf encoding in netdev-9 image, according to https://developers.google.com/protocol-buffers/docs/encoding : In netdev-9.img binary representation of sarg field is: "1a 2c 32 36 30 37 3a 66 30 64 30 3a 31 30 30 32 3a 30 30 35 31 3a 30 30 30 30 3a 30 30 30 30 3a 30 30 30 30 3a 30 30 30 34 0a c0 f4 a7 01" Field key is 0x1a - means type 2(Length-delimited field), field 3 - that is sarg field. Field len is 0x2c which is 44, first 40-byte "2607:f0d0:1002:0051:0000:0000:0000:0004\0" and then last 4 - "c0 f4 a7 01" where 0xc0 is not utf-8, and that makes crit fail. In sysctl_op we just read() from sysctl so no '\0' is added in the end of the string. So we can zero-init arrays and that will fix the issue. https://github.com/xemul/criu/issues/161 *Alternatively or additionaly we can put '\0' in the end of string in sysctl_read_char to make it harder to make such a mistake in future. Signed-off-by:
-
Tycho Andersen authored
Signed-off-by:
-
Tycho Andersen authored
Signed-off-by:
-
Pavel Tikhomirov authored
use native SYSCTL_TYPE__CTL_32 and SYSCTL_TYPE__CTL_STR v2: add BUILD_BUG_ONS to check SysctlType constants are equal to __CTL_STR and CTL_32, change __CTL_STR to CTL_STR in SysctlType enum. Signed-off-by:
-
Cyrill Gorcunov authored
For more convenient log parsing. Reported-by:
-
Cyrill Gorcunov authored
Not exported anywhere. Signed-off-by:
-
Andrew Vagin authored
man of inet_ntop says that INET_ADDR_LEN should not be less than INET_ADDRSTRLEN and INET6_ADDRSTRLEN Signed-off-by:
-
