Re: [PATCH RESEND] time: Fix sleeptime injection for non-stop clocksource & persistent clock

From: Mukesh Ojha
Date: Wed May 30 2018 - 06:27:14 EST


Hi John,


On 5/30/2018 7:50 AM, John Stultz wrote:
On Tue, May 29, 2018 at 2:49 AM, Mukesh Ojha <mojha@xxxxxxxxxxxxxx> wrote:
Currently, for both non-stop clocksource and persistent clock
there is a corner case, when a driver failed to go suspend mode
rtc_resume() injects the sleeptime as timekeeping_rtc_skipresume()
returned 'false' due to which we can see mismatch in time between
system clock and other timers.

Success case:
{sleeptime_injected=true}
rtc_suspend() => timekeeping_suspend() => timekeeping_resume() =>
rtc_resume()

Failure case:
{failure in sleep path} {sleeptime_injected=false}
rtc_suspend() => rtc_resume()

Signed-off-by: Mukesh Ojha <mojha@xxxxxxxxxxxxxx>
I'm not sure this patch makes sense yet (since I don't really see how
its used

In a system where both non-stop clocksource and rtc exist

Timestamp mismatch seen between a (Gyro)timer based on non-stop clocksource
and system clock after attempting a sleep.
Here, System clock timestamps increase by some millisecond as compare to
other timer.

And we see this is possible only when timekeeping_resume() has not been called
which is keeping sleeptime_injected to its default value(false). So, the call to
timekeeping_rtc_skipresume() in rtc_resume() is false and thats ends up in
sleeptime injection via rtc_resume().


When timekeeping_resume() has not been called means one of the driver failed
during suspend in syscore_suspend() in kernel/power/suspend.c .

So if we let rtc inject the sleeptime here, we would see the timestamp increase in case of
system clock.

- mind cc'ing me on the patch that makes use of this?)

And more problematic, the patch doesn't seem to apply to mainline.
Could you respin and resend?

Will spin the patch again with some minor code change.

Thanks,
Mukesh


thanks
-john