On Wed, Mar 18, 2015 at 11:17 AM, Cyrill Gorcunov <[email protected]> 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. > >> Also, what's up with CPREG1(gs) and CPREG1(fs)? I assume that's >> redundant, because that hasn't worked for many years, but CRIU works, >> so there must be correct code somewhere to restore those regs. > > Basically the initial registers values are fetched with ptrace > when program is been dumped, then on restore we copy them back > into sigcontext. That said we don't mangle fs/gs anyhow simply > restore the values back from dump.
Wouldn't it be a little safer to have the kernel make you a sane sigcontext by raising a signal and catching it rather than writing a new one from scratch? Grr, maybe the kernel should version its sigcontext structures. Getting fs from ptrace and restoring it to sigcontext is useless -- ptrace handles fs correctly, but that sigcontext field is just padding. Is CRIU at least reliably putting zero in the ss field? If so, we could add a special case to translate zero to __USER_DS on restore. (And then I'll update my test case, and we'll have to document it, etc.) --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/
