Re: [PATCHv2 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO_*

[Andy Lutomirski <luto@amacapital.net>]

On Wed, Jun 29, 2016 at 3:57 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> Add API to change vdso blob type with arch_prctl.
> As this is usefull only by needs of CRIU, expose
> this interface under CONFIG_CHECKPOINT_RESTORE.

> +#ifdef CONFIG_CHECKPOINT_RESTORE
> +       case ARCH_MAP_VDSO_X32:
> +               return do_map_vdso(VDSO_X32, addr, false);
> +       case ARCH_MAP_VDSO_32:
> +               return do_map_vdso(VDSO_32, addr, false);
> +       case ARCH_MAP_VDSO_64:
> +               return do_map_vdso(VDSO_64, addr, false);
> +#endif
> +

This will have an odd side effect: if the old mapping is still around,
its .fault will start behaving erratically.  I wonder if we can either
reliably zap the old vma (or check that it's not there any more)
before mapping a new one or whether we can associate the vdso image
with the vma (possibly by having a separate vm_special_mapping for
each vdso_image.  The latter is quite easy: change vdso_image to embed
vm_special_mapping and use container_of in vdso_fault to fish the
vdso_image back out.  But we'd have to embed another
vm_special_mapping for the vvar mapping as well for the same reason.

I'm also a bit concerned that __install_special_mapping might not get
all the cgroup and rlimit stuff right.  If we ensure that any old
mappings are gone, then the damage is bounded, but otherwise someone
might call this in a loop and fill their address space with arbitrary
numbers of special mappings.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>