[CRIU] [PATCH 09/10] restore: Add restoration of alternative signal stack, v2

[Cyrill Gorcunov]

On Tue, Jul 09, 2013 at 08:19:59PM +0400, Pavel Emelyanov wrote:
> 
> > +#define SAS_INVALID_SP		(-1ull)
> 
> This one can be (u64)-casted here to avoid casts where used.

ok. I think it might be simply set to -1 as well, since sign
will be propagated where needed. but'll recheck.

> > +	/*
> > +	 * On restore we have 2 ways for sas
> > +	 * - either call for sigaltstack explicitly in restorer.c right before
> > +	 *   we call for sigreturn
> > +	 *
> > +	 * - either pass stack value to sigreturn call and allow the kernel to
> > +	 *   restore stack for us
> > +	 *
> > +	 * Second way looks more clean and simple, and here we go.
> > +	 */
> > +	setup_sas(sigframe, core->thread_core->sas);
> 
> This thing is
> 
> a) called w/o checks for sas being valid (SAS_INVALID_SP)
> b) called for parasite code
> 
> Why is a) and does b) also work?

setup_sas does check that ->sas is not null, thus in protobuf
format it's either valid pointer to sas data or NULL otherwise.

SAS_INVALID_SP in turn introduced solely for restorer code,
if no sas present in image we assign sas_sp = -1 and restorer
code knows that there is no sas to handle with (this -1 came
from you, when you said I should not use has_sas field in
task_args but instead use some predefined value such as -1).

Summary

 - thread_code->sas either valid pointer to sas or NULL if
   there is no sas present

 - -1 used only in restore to inform restorer pie code that
   no sas present in image and we should not try to restore
   it on sigreturn

	Cyrill