linux-kernel - Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.21.1811212129520.275@nippy.intranet>
Date:   Wed, 21 Nov 2018 22:14:03 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
cc:     Kars de Jong <jongk@...ux-m68k.org>,
        Philip Blundell <philb@....org>,
        Andreas Schwab <schwab@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        Stephen N Chivers <schivers@....com.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Michael Schmitz <schmitzmic@...il.com>,
        John Stultz <john.stultz@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:

> > This suggests that either 0 or N (the latched value) would result from 
> > a read from the counter immediately following an interrupt. Who can 
> > say which? Just have to try it. The answer should allow us to avoid 
> > the risk of a clocksource that jumps forwards and backwards.
> 
> The code in amiga_gettimeoffset() does:
> 
>         ticks = hi << 8 | lo;
> 
>         if (ticks > jiffy_ticks / 2)
>                 /* check for pending interrupt */
>                 if (cia_set_irq(&ciab_base, 0) & CIA_ICR_TA)
>                         offset = 10000;
> 

That _suggests_ that there's no interrupt when ticks == 0.

But look what happens next:

>         ticks = jiffy_ticks - ticks;
> 
>         ticks = (10000 * ticks) / jiffy_ticks;
> 
>         return (ticks + offset) * 1000;

If (hi << 8 | lo) == 0, and you set offset = 10000, then the return value 
would be maximal.

Let's immediately call this function again. This time (hi << 8 | lo) == N. 
Let's add the offset again. I'm afraid the clock just jumped backwards.

So the logic you quoted has a rationale which is unrelated to the 
question.

--