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]
Date:   Tue, 5 Mar 2019 20:55:21 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
cc:     Andreas Schwab <schwab@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        Stephen N Chivers <schivers@....com.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kars de Jong <jongk@...ux-m68k.org>,
        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: [PATCH v4 00/14] m68k: Drop arch_gettimeoffset and adopt
 clocksource API

On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:

> On Tue, Mar 5, 2019 at 7:13 AM Finn Thain <fthain@...egraphics.com.au> wrote:
> > On Sat, 1 Dec 2018, Finn Thain wrote:
> > > This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k
> > > and converts users of arch_gettimeoffset to the clocksource API.
> > > Various bugs are fixed along the way.
> >
> > Are there any plans to merge this series, Geert?
> 
> Has this been tested on all/most platforms? Or do you think is it safe to
> apply regardless?
> 

The amiga, atari and mac patches have been tested.

The apollo, q40, sun3 and sun3x patches are safe though untested, AFAIK. I 
confirmed that, in qemu at least, the default jiffies clocksource will 
work, and the patch is trivial.

That leaves bvme6000, hp300, mvme147 and mvme16x. Those have not been 
tested. Here are some options for those platforms:

1) Apply the patches untested (gaining new clocksources and some API 
modernization for m68k, while fixing old bugs and potentially introducing 
new bugs).

2) Do nothing until someone tests the patch series on those 4 platforms.

3) Rewrite patches such that those 4 platforms get the same treatment as 
apollo, q40, sun3 and sun3x (this plan was already nak'd in the hp300 
case).

4) Keep using the gettimeoffset API. Redo the patch series to keep the bug 
fixes for the 3 platforms that can be readily tested. When the API change 
becomes unavoidable, remove difficult platforms.

Maybe there are other possibilities?

-- 

> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ