[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