criu dump will block at arm64? #150
Labels
Comments
|
The same issue on Raspberry pi 2. please refer to: https://lists.openvz.org/pipermail/criu/2016-April/027494.html |
|
OK, I've put Christopher Covington in Cc. He's now the one who ... kinda maintains the arm/aarch64 port. |
|
Hey, @datawolf, could you please test if it works with the following patch over criu-dev branch? https://lists.openvz.org/pipermail/criu/2016-April/027743.html |
|
Sorry, It does not work. here is the make dry-run after apply the patch: |
|
Maybe the patch has some wrong, When I change To The command |
|
@datawolf, thanks, I will check with qemu on the monday. Seems like, for arm64 problem was about missing linking against lib.a(on master), native.lib.a(on criu-dev). |
|
@0x7f454c46 ping, any progress about this bug? |
|
@datawolf I'm on it, will give a reply/patch today. |
|
Ok, so the patch I did was ok, except ARCH filter should be not with arm64, but with aarch64. |
|
So the problem is that gcc v5.3 creates relative relocs for |
|
@0x7f454c46 I use gcc v4.9.2, and it can dump OK. But the restore run failed. Could you please help to solve the restore failed problem? the tail of the restore.log is: |
|
@datawolf, could you test it with the following patch: https://lists.openvz.org/pipermail/criu/2016-May/028247.html |
criupatchwork
pushed a commit
to criupatchwork/criu
that referenced
this issue
May 11, 2016
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 checkpoint-restore#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,checkpoint-restore#112] ; saving it on stack on ; function's begin 0x14188: ldr x2, [x29,checkpoint-restore#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: checkpoint-restore#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: Dmitry Safonov <dsafonov@virtuozzo.com>
|
@0x7f454c46 It works. Thank you. |
|
@datawolf thanks for testing :) |
xemul
pushed a commit
that referenced
this issue
May 11, 2016
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: Dmitry Safonov <dsafonov@virtuozzo.com> Tested-by: long.wanglong <long.wanglong@huawei.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
xemul
pushed a commit
that referenced
this issue
May 16, 2016
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: Dmitry Safonov <dsafonov@virtuozzo.com> Tested-by: long.wanglong <long.wanglong@huawei.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
tkhai
pushed a commit
to tkhai/criu
that referenced
this issue
May 17, 2016
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 checkpoint-restore#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,checkpoint-restore#112] ; saving it on stack on ; function's begin 0x14188: ldr x2, [x29,checkpoint-restore#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: checkpoint-restore#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: Dmitry Safonov <dsafonov@virtuozzo.com> Tested-by: long.wanglong <long.wanglong@huawei.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
xemul
pushed a commit
that referenced
this issue
May 30, 2016
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: Dmitry Safonov <dsafonov@virtuozzo.com> Tested-by: long.wanglong <long.wanglong@huawei.com> Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, all
I built criu on arm64, the version is :
and test criu with the following steps:
the tail of dump.log is :
The tail output of
strace criu dump -t 15917 -vvv -o dump.log && echo OKIt blocked at accept system call.
I would like to ask for ideas, how this problem can be solved.
The text was updated successfully, but these errors were encountered: