[CRIU] Fwd: Checkpoint failure on arm64 platform

[Christopher Covington]

Hi Vijay,

On 12/23/2015 12:18 AM, Vijay Kilari wrote:

>> Try running the test code attached to the following email:
>>
>> https://lists.openvz.org/pipermail/criu/2015-March/019161.html
> 
> The output of test code is as follows
> 
> ubuntu at ubuntu:~/criu$ mv attachment.bin attachment.c
> ubuntu at ubuntu:~/criu$ gcc attachment.c
> ubuntu at ubuntu:~/criu$ ./a.out
> [40136] vdso: 0x3ff862c0000 - 0x3ff862d0000
> [40136] vdso moved to: 0x3ff86130000 - 0x3ff86140000
> [40136] sending SIGUSR1 signal to myself
> [40136] Caught signal 10 (siginfo=0x3ffe3dce770)
> [40136]    siginfo=[si_signo=10, si_pid=40136, si_uid=1000]
> Segmentation fault (core dumped)
> ubuntu at ubuntu:~/criu$
> 
>> If that crashes, try the following patch:
>>
>> http://www.spinics.net/lists/linux-arm-msm/msg18291.html
> 
> After applying this patch
> 
> ubuntu at ubuntu:~/criu$ ./a.out
> [1493] vdso: 0x3ff93270000 - 0x3ff[   98.900231] pgd = fffffe03cd450000
> 93280000
> [1493] vdso moved to: [   98.906466] [00000500]
> *pgd=00000003cee600030x3ff930e0000 - 0x3ff930f0000
> [, *pud=00000003cee600031493] sending SIGUSR1 signal to ,
> *pmd=00000003cee60003myself
> [1493] Caught signal 10 , *pte=0000000000000000(siginfo=0x3ffc4e3f0c0)
> [1493]
> siginfo=[si_signo=10, si_pid=1493, si_uid=1000]
> Segmentation fault (core dumped)
> ubuntu at ubuntu:~/criu$

Doesn't look like the patch does anything :(. My patch depends on
Laurent Dufour's work which was merged in 4.2 but it sounds like you
should already have those dependencies (f2abee, 83d3f0, 4abad2, 2ae416).

>> While commit 871da9 seemed to fix the issue for cross-compilation using
>> Linaro compilers, native building under Arch results in the char
>> *vdso_symbols requiring relocations. We're currently getting by with a
>> hacky workaround. Unless some compiler option that we've not yet tried
>> gets GCC to actually generated position independent code, piegen
>> probably will need to be ported to AArch64 (and perhaps AArch32 as well)
>> to resolve the load-time relocations.
> 
> Assuming the vdso mapping is already done in vdso_init()
> for vdso_rt and vdso_vvar,
> I have tried dirty workaround where I removed vdso mapping
> in pie/restorer.c from __export_restore_task() function. This change
> worked. checkpoint and restore worked.
> 
> #if 0
>         /*
>          * Proxify vDSO.
>          */
>         for (i = 0; i < args->vmas_n; i++) {
>                 if (vma_entry_is(&args->vmas[i], VMA_AREA_VDSO) ||
>                     vma_entry_is(&args->vmas[i], VMA_AREA_VVAR)) {
>                         pr_info("In %s calling vdso_proxify for i =
> %d\n",__func__, i);
>                         if (vdso_proxify("dumpee", &args->vdso_sym_rt,
>                                          args->vdso_rt_parked_at,
>                                          i, args->vmas, args->vmas_n))
>                                 goto core_restore_end;
>                         break;
>                 }
>         }
> #endif

Our current use case is running trusted tools and workloads with as much
determinism as possible, so we generally turn off address space layout
randomization (using the norandmaps kernel parameter) which has a side
effect of skipping the VDSO proxy step.

Regards,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project