[CRIU] VM_IO or VM_PFNMAP mappings

[Cyrill Gorcunov]

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?

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.