[BUG] etnaviv: broken timeouts

[Arnd Bergmann]

On Mon, Nov 6, 2017 at 3:17 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Mon, Nov 6, 2017 at 3:04 PM, Russell King - ARM Linux
> <linux at armlinux.org.uk> wrote:
>> On Mon, Nov 06, 2017 at 01:42:10PM +0100, Arnd Bergmann wrote:
>>> On Mon, Nov 6, 2017 at 11:35 AM, Lucas Stach <l.stach at pengutronix.de> wrote:
>> Could you look at the patches I proposed, which have been tested,
>> instead of recreating my work?
>>
>> If you want to recreate my work, we're going to have to wait another
>> 50 odd days before we can say whether they work or not, because that's
>> how long it takes for the current code to go wrong, and I've already
>> rebooted the platforms.
>
> I'll have a look, sure.

I found your patches in the web archive (the timespec and timespec64
based ones) now, and they look correct regarding the INITIAL_JIFFIES
and NTP clock drift issues, as well as the overflow of the jiffies.

However, the comment you introduce is a bit misleading in the 'timespec'
version:

> +/*
> + * Etnaviv timeouts are specified wrt CLOCK_MONOTONIC, not jiffies.
> + * We need to calculate the timeout in terms of number of jiffies
> + * between the specified timeout and the current CLOCK_MONOTONIC time.
> + * Note: clock_gettime() is 32-bit on 32-bit arch.  Using 64-bit
> + * timespec math here just means that when a wrap occurs, the
> + * specified timeout goes into the past and we can't request a
> + * timeout in the future: IOW, the code breaks.
> + */

We already know that we will fix clock_gettime() to return 64-bit
seconds in the future, and at that point the comment no longer
makes any sense.

We also know that CLOCK_MONOTONIC doesn't overflow 32-bit
interfaces in practice, and we rely on that in lots of places in the
kernel, but we still use ktime_t or timespec64 with clock_monotonic
for consistency with the future fixed user space.

       Arnd