[CRIU] VM_IO or VM_PFNMAP mappings

[Pavel Emelyanov]

On 10/27/2014 05:04 PM, Cyrill Gorcunov wrote:
> On Mon, Oct 27, 2014 at 03:51:26PM +0400, Pavel Emelyanov wrote:
>> 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?
> 
> It would be great to know the background of this conversation, what the
> problem was in the first place?

Sowmini has found pfnmap mapping while dumping the iperf tool. While
researching the issue he discovered this calltrace.

The original discussion happened under the "[CRIU] criu + threaded
program + TCP_REPAIR" subject.

> As to stack backtrace -- this is standart setup of a new memory map
> for Elf executable. The new vDSO format (well, relatively new, since 3.16)
> implies presence of vvar zone which has  VM_IO | VM_PFNMAP flags, this
> area prepared to the process by the kernel. So guys, could you please
> describe what the problem we're trying to solve here.
> 
>>
>>> 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.
> .
>