Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

[Cyrill Gorcunov <gorcunov@gmail.com>]

On Thu, Mar 19, 2015 at 09:08:08AM -0700, Andy Lutomirski wrote:
> >> >
> >> >> So... do we introduce somewhat nasty code into the kernel to keep old
> >> >> CRIU versions working, or do we require that users who want to restore
> >> >> onto new kernels use new CRIU?
> >> >
> >> > It's OK (I think) to require newer versions of CRIU, it's easy to update
> >> > one unlike the kernel ;)
> >> >
> >> > But if "old" version of CRIU just crash the restored processes on "new"
> >> > kernels and there's no way to detect this properly -- that's the problem.
> >>
> >> Yeah, that's unfortunate.
> >>
> >> I don't have a great idea for how to work around this, unfortunately.
> >> Ideally we'd increment some kind of version counter or use an
> >> extension mechanism rather than shoving ss into a field that used to
> >> be padding.
> >
> > fwiw currently we're passing zero in this __pad0 (replying to your
> > previous email, so we can workaround in the kernel assuming zero
> > as a special case, not that good but better than nothing).
> 
> We could store ss_plus_one instead of ss.  Yuck.

Heh, sounds like ugly-dirty-hack ;)

> The only real down side I can see to special casing zero is that it
> really is possible to end up with zero in there.  For example, the
> SIGSEGV you get do to the failed sigreturn probably has sigcontext->ss
> == 0 :)

Sure we;ve failed for exactly this reason simply because we've it
zeroified manually :) So there is no simple workaround in the kernel
for programs dumped before the kernel fix and restored on new kernel
where this patch exist but criu is old enough and has no Oleg's fix.