On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
