RE: Ensuring wall_to_monotonic is not positive breaks use case

[Rick Ratzel]

On Sat, 15 Sep 2018, Thomas Gleixner wrote:
> > 
> > So reverting this is not really an option.

> Maybe we can :)

Thanks for checking into this more.  We've been looking at the uses you described, and hopefully we can have something to submit for review (or at least discuss) relatively soon.

>
> We have 3 users in tree:
>
> 1) /proc/stat btime
>
>    It's trivial enough to clamp that value to 0, though it might be
>    surprising for some users as uptime will tell something different.
>

Agreed.

> 2) sunrpc
>
>    I think that can be converted to actually use CLOCK_BOOTTIME. This needs
>    a bit of trickery to preserve the user space interfaces which are
>    CLOCK_REALTIME based, but it should be doable.
>

It looks like this can use CLOCK_BOOTTIME as you describe, but "properly" converting to the REALTIME timescale might be hard, as you noticed. One proposal is to floor the conversion to the Epoch, just like your proposal to floor /proc/stat btime to 0, but we're not sure how that'll impact users yet.

> 3) x86/kvm
>
>    That's actually the trickiest part of all and I haven't yet fully
>    analyzed it, whether there is an issue that time can go negative.
>
>    Actually there shouldn't be one as this is about wall time and that
>    cannot go before the epoch. Needs some close inspection and while it
>    might be trivial to adapt the code in question, it could be tricky or
>    even impossible to fix it without breaking existing guests.

We're still looking at this one as well...

-Rick