On Wed, Mar 18, 2015 at 11:25 AM, Oleg Nesterov <[email protected]> wrote: > On 03/18, Cyrill Gorcunov wrote: >> >> On Wed, Mar 18, 2015 at 11:06:00AM -0700, Andy Lutomirski wrote: >> > > --- a/arch/x86/crtools.c >> > > +++ b/arch/x86/crtools.c >> > > @@ -475,6 +475,7 @@ int restore_gpregs(struct rt_sigframe *f, >> > > UserX86RegsEntry *r) >> > > CPREG2(rip, ip); >> > > CPREG2(eflags, flags); >> > > CPREG1(cs); >> > > + CPREG1(ss); >> > > CPREG1(gs); >> > > CPREG1(fs); >> > >> > Huh? Is CRIU actually trying to build an entire sigcontext from >> > scratch here? I don't see how this can reliably work across kernel >> > versions or CPU versions. >> >> Yes we are. And why it can't work reliably? As to CPU -- we're >> testing that cpu features saved in image should match ones >> provided by the kernel runtime, ie on the machine where we're >> restoring. > > But, say, __USER_CS can be changed in kernel, and nobody should notice this.
This actually happens on a regular basis. Has anyone tried checkpointing on Xen and restoring on native? Xen does interesting things to cs and possibly to ss as well on x86. You get somewhat of a free pass on ds and es because the kernel's context switch code is very tolerant of failures there. --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/
