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

Dmitry Safonov dsafonov at virtuozzo.com
Thu Jul 28 09:15:01 PDT 2016


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


More information about the CRIU mailing list