Re: [patch 0/6] timekeeping: Cure the signed/unsigned wreckage

[John Stultz]

On Thu, Dec 8, 2016 at 12:49 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> This series addresses the recently reintroduced signed vs. unsigned
> wreckage by cleaning up the whole call chain instead of just making a
> simple s64 -> u64 'fix' at one point and keeping the rest signed, which
> eventually led to the unintended signed conversion and brought back an
> issue that was fixed a year ago already.
>
> Here is the queue:
>
>   timekeeping: Force unsigned clocksource to nanoseconds conversions
>   timekeeping: Make the conversion call chain consistently unsigned
>   timekeeping: Get rid of pointless typecasts
>
> These three patches are definitely urgent material
>
>   timekeeping: Use mul_u64_u32_shr() instead of open coding it

Thanks for putting these together Thomas!

So I'm happy with the set above.


> Can wait for 4.11, but for sanity reasons it should go into 4.10
>
>   [RFD] timekeeping: Provide optional 128bit math
>
> This is material for discussion. I'm not sure if we want to do that at
> all, but it addresses the insanities of long time scheduled out VMs.

Yea. Here I feel like there has to be some bound after which we don't
function when we're starved of interrupts. On some systems it will be
the hardware clocksource wrapping, on other systems its the
multiplication overflowing.

I think we should avoid the system failing critically (which the
initial patches address), as there are cases like halting the system
via kdb or freezing a VM for a long period of time (hosts suspending
is an example), but having a smallish time inconsistency event in this
case doesn't seem tragic to me.

Providing a config option for folks who want robust time correctness
in the event of insane system scheduling/interrupt latency isn't
something I object to, but I worry it will just push the boundary of
what is "expected broken by design" out further (why bother
suspending/resuming the timekeeping subsystem when you can just starve
it, etc).

thanks
-john