[CRIU] weird usleep() behaviour on dump

[Dmitry Safonov]

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.. ;-)

-- 
          Dima