[CRIU] weird usleep() behaviour on dump

[Radostin Stoyanov]

On 13/06/2019 19:35, Dmitry Safonov wrote:
> On 6/13/19 7:27 PM, Andrei Vagin wrote:
>> Cc: Dima
>>
>> On Thu, Jun 13, 2019 at 6:10 AM Radostin Stoyanov <rstoyanov1 at gmail.com> wrote:
>>> Hi Andi,
>>>
>>> On 13/06/2019 13:31, andi wrote:
>>>> Hi guys!
>>>>
>>>> I’m running CRIU 3.11 on a 4.9 ARM64 Kernel.
>>>>
>>>>
>>>> I’m observing the following. If I have a simple C-Program that sleeps
>>>> for 5 seconds (usleep(5000000)), and if I dump it after 3 seconds,
>>>> then the sleep will take 8 seconds. If I dump it periodically every
>>>> second, the usleep() will never return, and from the moment I stop
>>>> dumping until it returns it will take 5 seconds.
>> Could you run strace -fo strace.log -s 256 criu restore .... and send
>> us the strace.log file?
>>
>>>>
>>>> So it looks as if usleep() got restarted with every dump.
>>>>
>>>> Do you guys have an idea why that is? Where it happens?
>>>>
>>> It is likely that usleep() is interrupted by CRIU and if it is called
>>> within a loop it will start again.
>> Why do we have some logic about restarting system calls for x86 and
>> don't have something similar for aarch64?
>>
>> https://github.com/checkpoint-restore/criu/blob/criu-dev/compel/arch/x86/src/lib/infect.c#L270
> Probably, because zdtm misses a test.. ;-)
>

I'm not sure about this. I tested the following example:

#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>

int main()
{
     int err, ret;
     ret = usleep(5000000);
     err = errno;
     printf("%d %s\n", ret, strerror(err));
     return 0;
}

After restore, the output is:
-1 Interrupted system call

When the --leave-running flag is used, the same output appears 
immediately after dump.

I think that this is expected behaviour and applications that use 
usleep() should handle EINTR.

Also usleep() is not a system call, and in the POSIX specification [1] 
is explicitly said:

The usleep() function shall cause the calling thread to be suspended 
from execution until either the number of realtime microseconds 
specified by the argument useconds has elapsed or a signal is delivered 
to the calling thread ...

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/usleep.html

Radostin