[CRIU] [RFD] (v)omitting vDSO PFN check in CRIU

[Dmitry Safonov]

Hi guys, criu-ml, et al.

I want to hear your opinions on my proposed solution to a bug.

Currently, here we have:
1. During checkpointing criu searches vdso vma in dumpee.
    It's done by looking into /proc/../maps during maps parsing.
2. Pre-v3.16 kernels lose "[vdso]" naming for vma if vdso was
    mremap()'ed. Futhermore, such kernels may return "[vdso]"
    name for non-vdso vma if such vma was placed on position,
    from which vdso vma was moved with mremap().
    That's because arch_vma_name() returns on pre-v3.16 kernels
    hint "[vdso]" if vma.start_addr <= mm->context.vdso, where
    mm->context.vdso was never updated.
3. To differ real vdso vma from other vmas, criu uses pagemap
    for criu to find vdso's pfn and compares it with dumpee's.
    If pfn for vma, which previously from /proc/../maps was
    supposed to be vdso, differs from criu's vdso pfn,
    such vma is considered to be mishinted and is dumped as
    usual anonymous area.

It all worked good, till we added to vzkernel uname and time-monotonic
virtualization: that virtualization results in uniq physical pages for
vdso per-CT. That means that two processes in one CT1 will have the
same physicall address for vdso, but process A from CT1 and process B
from CT2 will have different physicall addresses for vdso.
So, today with @ptikhomirov on Jenkins with vz7 we found that every
process in a new UTS-ns gets during dump mishinted vdso address
(as uts-ns vdso's pfn differ from init-uts-ns's vdso pfn).

Here is what I propose as a solution:
o Add a kdat test, which tests if "[vdso]" hint stays after mremap() of
vdso area.
o Don't use checking of vdso's pfn during dumping if the hint stays.

@xemul, I know that you don't welcome checks for non-mainstream
features, such as uname and gtod virtualization.
But, I think this way will suit *both* ms and vz platforms.
Reason, why it's good for ms criu version is that we will skip
open(), read(), close() for pagemap per each dumpee (for all kernels
newer than v3.16). That's a hole bunch of syscalls!

So, does the rework of vDSO PFN check to kdat test for "[vdso]" hint
after mremap() sounds sane?
Opinions?
Other suggestions?

-- 
              Dmitry