Skip to content

C
criu
Switch branch/tag
  1. 01 Jun, 2016 25 commits
  3. 31 May, 2016 9 commits
  5. 30 May, 2016 6 commits
    • Dmitry Safonov's avatar
      Makefile: suppress git describe warnings · fa8b12a1
      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: 's avatarDmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: 's avatarCyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      fa8b12a1
    • Pavel Tikhomirov's avatar
      crit/decode: set default opts['nopl'] to False · 39cbd916
      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: 's avatarPavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      39cbd916
    • Pavel Emelyanov's avatar
      crit: Show no payload for image objects · 4ead1592
      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: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      4ead1592
    • Dmitry Safonov's avatar
      aarch64/pie/util-vdso: workaround for vdso_symbols relocation · f77cb858
      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: 's avatarDmitry Safonov <dsafonov@virtuozzo.com>
Tested-by: 's avatarlong.wanglong <long.wanglong@huawei.com>
Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      f77cb858
    • Dmitry Safonov's avatar
      parasite-vdso: add casts from uint64_t · de71b6d6
      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: 's avatarDmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: 's avatarCyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      de71b6d6
    • Cyrill Gorcunov's avatar
      build: Generate criu version from toplevel · a870a170
      Cyrill Gorcunov authored 
      Signed-off-by: 's avatarCyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: 's avatarDmitry Safonov <dsafonov@virtuozzo.com>
Signed-off-by: 's avatarPavel Emelyanov <xemul@virtuozzo.com>
      a870a170