Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit kernel

[Andy Lutomirski]

On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>>>
>>> The real issue is that happens if the process is checkpointed while
>>> inside the vdso and now eip/rip or a stack frame points into the vdso.
>>> This is not impossible or even unlikely, especially on 32 bits it is
>>> downright likely.
>>
>> I fear if there are stacked ip which point to vdso -- we simply won't
>> be able to restore properly if vdso internal format changed significantly
>> between kernel versions. (At moment we restore vdso exactly at same position
>> it was on checkpoint stage with same content, iirc).
>>
>
> I don't think there is a way around that.  It is completely unreasonable
> to say that the vdso cannot change between kernel versions, for obvious
> reasons.  It's worse than "significantly"... changing even one
> instruction makes it plausible your eip/rip will point into the middle
> of an instruction.

It's not just kernel versions -- different toolchains may generate
different code.  Heck, building from a different directory can
sometimes generate different output.

The ABI of each vdso function is stable, though -- a sufficiently
clever tool could (maybe) use that knowledge along with unwind data in
the vdso to fix everything up.  This would be interesting, perhaps,
but certainly not easy.

I say we declare "if you want a working vdso in a weird location,
mremap it".  But how does userspace figure out what size to pass to
mremap?  If it's one vma, it's easy.

I don't know all that much about the linux vm.  Can we create a
special vdso address_space or struct inode or something so that a
single vma can contain pages with different flags?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/