[CRIU] clock_gettime(MONOTONIC) changing after restore

[Christopher Covington]

Hi Cyrill,

On 08/03/2015 08:53 AM, Cyrill Gorcunov wrote:
> On Mon, Aug 03, 2015 at 08:31:31AM -0400, Christopher Covington wrote:
>> Hi,
>>
>> We have notice clock_gettime(MONOTONIC) calls changing significantly across
>> checkpoint and restore using CRIU circa 1.3-rc2. We'll be moving to the latest
>> tip soon, but I was wondering if anyone knew off the top of their head whether
>> we should expect different behavior from a newer CRIU, or if
>> clock_gettime(MONOTONIC) (maybe CLOCK_MONOTONIC* and CLOCK_BOOTTIME?) should
>> be listed on the following wiki page:
>>
>> http://criu.org/What_can_change_after_C/R
> 
> Could you provide mode detals please (which values are not adjusted?).
> Currently we try to adjust timer's values if they were set to absolute
> time (pie/restorer.c:613). This concerns timerfd only. If the problem
> in result of clock_gettime syscall itself -- then we indeed do not
> intercept this calls neither adjust their results.

We're looking at a Java application that calls System.nanoTime().

http://stas-blogspot.blogspot.com/2012/02/what-is-behind-systemnanotime.html

Perhaps the folks on this list can think of better ways to handle this, but
the following come to mind:

A) LD_PRELOAD a wrapper that fixes up the clock_gettime system call. This
works for the issue we're seeing, but it wouldn't handle statically compiled
executables or hand-coded clock_gettime system calls.

B) Change the kernel to allow setting the monotonic clock. The whole point of
the monotonic clock is that it can't be modified at run time, but maybe a boot
parameter would be acceptable? One would have to estimate and add in the time
it takes for the system to boot/kexec and run CRIU restore.

C) Fix up the gettime system call using ptrace syscall, presumably adversely
affecting performance.

D) If the gettime system call goes through the VDSO, ptrace poke some code to
fix it up there.

Thanks,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project