[CRIU] [PATCH 7/8] restore: Add restoration of alternative signal stack

[Andrew Vagin]

On Tue, Jun 18, 2013 at 05:17:18PM +0400, Cyrill Gorcunov wrote:
> On Tue, Jun 18, 2013 at 04:55:39PM +0400, Andrew Vagin wrote:
> > > --- a/pie/restorer.c
> > > +++ b/pie/restorer.c
> > > @@ -733,6 +733,15 @@ long __export_restore_task(struct task_restore_core_args *args)
> > >  		goto core_restore_end;
> > >  
> > >  	/*
> > > +	 * FIXME
> > > +	 * Alternative signal stack for the group leader
> > > +	 * is setting up separately from the threads.
> > > +	 * This better should be unified one day.
> > > +	 */
> > > +	if (args->has_sas)
> > > +		setup_sas(rt_sigframe, &args->sas);
> > > +
> > 
> > I think would be better if setup_sas will be called after restore_signals,
> > because before this moment SIGCHLD isn't blocked.
> > 
> > Can you explain how that works for nested signal handlers?
> 
> setup_sas does only one thing -- it prepares sigreturn frame, thus once
> sigreturn called the kernel sets up alternative signal frame for the
> task, iow simultaneously with setting up new cs:ip. So I don't get how
> it's related to nested signal handlers.

It was off topic question.

> If I understand you correctly
> the SIGCHLD which might be called there is handled by our code with our
> own signal handler, no?
yes. But when I wrote this message I did not know that altstack is used
only for SA_ONSTACK, so we can restore sas here.

> In turn former blocked signals mask is restored
> sigreturn too, thus (if only I've not missed something obvious) -- we're
> allowed to restore sas with sigreturn help insted of explicit calling
> for sigaltstack() system routine.

So why do we call sigaltstack?