[CRIU] VM_IO or VM_PFNMAP mappings

Sowmini Varadhan sowmini.varadhan at oracle.com
Sun Oct 26 14:40:20 PDT 2014



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

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.


More information about the CRIU mailing list