Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 14 Dec 2012 13:27:04 -0800 | Subject | Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit kernel |
| |
On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin <hpa@zytor.com> 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
| |