[CRIU] [PATCH] dump: don't call rollback actions from a signal handler

[Andrew Vagin]

On Thu, Jul 28, 2016 at 07:15:01PM +0300, Dmitry Safonov wrote:
> On 02/23/2016 02:33 AM, Andrey Vagin wrote:
> > From: Andrew Vagin <avagin at virtuozzo.com>
> > 
> > We can do this, but we need to be sure that all structures
> > are consistant in any moment and we need to block alarm when
> > they are inconsistant.
> > 
> > I don't think that we really want to do this now. I suggest to
> > interupt a current syscall if an alarm signal is triggered.
> > 
> > https://jira.sw.ru/browse/PSBM-44371
> > 
> > v2: print an error message before exiting
> > Cc: Andrey Ryabinin <aryabinin at virtuozzo.com>
> > Signed-off-by: Andrew Vagin <avagin at virtuozzo.com>
> > ---
> 
> Excuses about necroposting on this, but can't SIGALRM interrupt the
> syscall by which Glibc realizes alarm() function?

I think it can't. syscall can be interrupted if it waits something.

> I mean the following:
> 
> setup_alarm_handler();
> alarm(opts.timeout);
> /* ...some blocking work */
>                                  <-- SIGALRM
> /* returning from blocking work */
> alarm(0);                        <-- SIGALRM
> 
> which makes it kinda racy:
> after it we continue in error-path cleanups, but alarm_attempts isn't
> zero yet and SIGALRM may come again.
> 
> So, without alarm_attempts it was clean, what will happen:
> 
> setup_alarm_handler();
> alarm(opts.timeout);
> /* ...some blocking work */
> /* returning from blocking work */
> alarm(0);                        <-- SIGALRM
> 
> Cleaning up & exit in handler -- we're late for alarm(0) call.
> 
> And now? Does this makes sence?
> 
> -- 
>              Dmitry