[CRIU] VM_IO or VM_PFNMAP mappings

[Pavel Emelyanov]

On 10/27/2014 01:40 AM, Sowmini Varadhan wrote:
> 
> 
> About the problematic VM_IO or VM_PFNMAP that I encountered with 
> iperf...
> 
>> The only way here is to learn how to dump and restore such mappings.
>> Maybe this will be quite easy, I don't know. We just know that such
>> mappings cannot be dumped with the existing criu mechanisms.
>>
>> I can't say for sure when we will be able to have a look at this, but
>> if you are willing to try to handle it yourself -- we will be glad to
>> help by answering questions about criu and kernel.
> 
> Turns out these come up as a result of vdso
> [http://stackoverflow.com/questions/19938324/what-are-vdso-and-vsyscall]. 
> The stack trace is:
> 
>  [  123.107756]  [<ffffffff81196395>] remap_pfn_range+0xa5/0x480
>  [  123.107763]  [<ffffffff8106678b>] map_vdso+0x1ab/0x240
>  [  123.107769]  [<ffffffff810668ce>] compat_arch_setup_additional_pages+0x7e/0xc0
>  [  123.107774]  [<ffffffff81232a31>] load_elf_binary+0xac1/0x1830
>  [  123.107781]  [<ffffffff811e1587>] search_binary_handler+0x97/0x1d0
>  [  123.107787]  [<ffffffff811e29d1>] do_execve_common.isra.24+0x481/0x610
>  [  123.107794]  [<ffffffff811e2da9>] SyS_execve+0x29/0x30
>  [  123.107800]  [<ffffffff81765c09>] stub_execve+0x69/0xa0

Cyrill, do you know anything about VDSO remapping?

> So given that (for a start) one can never tell if the src and dst of
> the migration have vdso enabled, and anyway,  the best workaround
> for this might be to require that the src of the migration MUST NOT
> have vdso enabled- when I rebuilt my kernel with "Disable VDSO",
> I dont see the mapping any more.
> 
> But I still have problems with gettng p.haul migration to work.
> Let me describe the details in a separate mail for that.
> .
>