We use page frame number to detect vDSO which has been remapped
in-place from runtime vDSO during restore. In such case if the
kernel is younger than 3.16 the "[vdso]" mark won't be reported
in procfs output.

Still to address recently reported CVEs and be able to run CRIU
in unprivileged mode we need to handle vDSO without pagemap access
and here is the deal -- when we find VMA which "looks like" vDSO
we try to scan it for vDSO symbols and if it matches we restore
its status without PFN access.

Here is some details on @pagemap access in-kernel history:

 - @pagemap introduced in commit 85863e475e59 where anyone
   which can attach to a task via ptrace is allowed to read
   data from @pagemap (Feb 4 2008, v2.6.25-rc1)

 - in commit 006ebb40d3d65 ptrace attach rule has been changed
   into ptrace read permission (May 19 2008, v2.6.27-rc1)

 - in commit ab676b7d6fbf4 opening of @pagemap become guarded
   with CAP_SYS_ADMIN because of leak of physical addresses
   into userspace (Mar 9 2015, v4.0-rc5)

 - in commit 1c90308e7a77a opening of @pagemap become available
   for regular users again (with ptrace read permission) but
   physical addresses of pages are hidden from non-privileged
   userd (Sep 8 2015, v4.3-rc1)
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Looks-good-to-me: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>