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

[Pavel Emelyanov]

On 07/09/2013 08:46 PM, Cyrill Gorcunov wrote:
> 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.

OK. Let's assume we ptraced a task with SAS and injected a parasite
into it. Later for any reason the sigreturn rescue code started to
return from parasite. Would we restore it with proper SAS?

> 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
> .
>