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.1811202034350.258@nippy.intranet>
Date:   Wed, 21 Nov 2018 10:13:46 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Kars de Jong <jongk@...ux-m68k.org>
cc:     geert@...ux-m68k.org, philb@....org, schwab@...ux-m68k.org,
        arnd@...db.de, schivers@....com.au, tglx@...utronix.de,
        daniel.lezcano@...aro.org, schmitzmic@...il.com,
        john.stultz@...aro.org, linus.walleij@...aro.org,
        linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

On Tue, 20 Nov 2018, Kars de Jong wrote:

> Op ma 19 nov. 2018 om 02:10 schreef Finn Thain <fthain@...egraphics.com.au>:
> >
> > hp300_gettimeoffset() never checks the timer interrupt flag and will
> > fail to notice when the timer counter gets reloaded. That means the
> > clock could jump backwards.
> >
> > Remove this code and leave this platform on the 'jiffies' clocksource.
> > Note that this amounts to a regression in clock precision. However,
> > adopting the 'jiffies' clocksource does resolve the monotonicity issue.
> >
> > Signed-off-by: Finn Thain <fthain@...egraphics.com.au>
> > ---
> > hp300_gettimeoffset() cannot be used in a clocksource conversion
> > unless it can be made monotonic. I can't fix this without knowing the
> > details of the timer implementation, such as the relationship between
> > the timer count and the interrupt flag.
> 
> I don't really like this regression...
> 

Me neither...

I'll see if I can write a conversion patch based on the information you've 
provided. Can you test it?

> According to NetBSD sources, there are 3 timers in the chip (originally 
> an MC6840 PTM).

Thanks for the tip. I will examine the datasheet for the 6840.

I'll also take another look at the NetBSD code.

> Timer 1 is used as the system timer, timer 3 runs at the same rate and 
> is unused on Linux (on NetBSD it is used as the statistics/profiling 
> timer), and timer 3 is connected to timer 2 so you can make a 32-bit 
> timer out of the two timers together (also unused on Linux).
> 
> Timers 1 counts down at 25 MHz.

You mean, 250 kHz, right? The code in mainline programs the timer for 2500 
cycles, hoping to get 10 ms. That is, 250 cycles per ms.

> The interrupt flag is set when the counter reaches 0 after which it is 
> automatically reloaded and starts counting down again.
> 

Thanks.

On atari, the 68901 counts down to 0x01 and raises an interrupt. On mac, 
the 6522 counts down to 0xFFFF then raises an interrupt. No idea about 
amiga (Geert?) -- this has to be handled correctly to get a monotonic 
clocksource. I'll fix this in v3 (where the information is available).

-- 

> > ---
> >  arch/m68k/hp300/time.c | 19 -------------------
> >  1 file changed, 19 deletions(-)
>