linux-kernel - Re: [PATCH v3 7/7] clocksource: mips-gic-timer: Set limitations on clocksource/sched-clocks usage

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: <20200516121647.g6jua35kkihmw5r6@mobilestation>
Date:   Sat, 16 May 2020 15:16:47 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
CC:     Serge Semin <fancer.lancer@...il.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Paul Burton <paulburton@...nel.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Arnd Bergmann <arnd@...db.de>,
        Rob Herring <robh+dt@...nel.org>, <linux-mips@...r.kernel.org>,
        <linux-rtc@...r.kernel.org>, <devicetree@...r.kernel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 7/7] clocksource: mips-gic-timer: Set limitations on
 clocksource/sched-clocks usage

Hello Daniel,

Thanks for your comment. My response is below.

On Fri, May 15, 2020 at 07:10:04PM +0200, Daniel Lezcano wrote:
> On Thu, May 07, 2020 at 12:41:07AM +0300, Serge Semin wrote:
> > Currently neither clocksource nor scheduler clock kernel framework
> > support the clocks with variable frequency. Needless to say how many
> > problems may cause the sudden base clocks frequency change. In a
> > simplest case the system time will either slow down or speed up.
> > Since on CM2.5 and earlier MIPS GIC timer is synchronously clocked
> > with CPU we must set some limitations on using it for these frameworks
> > if CPU frequency may change. First of all it's not safe to have the
> > MIPS GIC used for scheduler timings. So we shouldn't proceed with
> > the clocks registration in the sched-subsystem. Secondly we must
> > significantly decrease the MIPS GIC clocksource rating. This will let
> > the system to use it only as a last resort.
> >
> > Note CM3.x-based systems may also experience the problems with MIPS GIC
> > if the CPU-frequency change is activated for the whole CPU cluster
> > instead of using the individual CPC core clocks divider.
> 
> May be there is no alternative but the code looks a bit hacksih. Isn't possible
> to do something with the sched_mark_unstable?
> 
> Or just not use the timer at all ?

Not using the timer might be better, but not that good alternative either
especially in our case due to very slow external timer. Me and Thomas
Bogendoerfer discussed the similar commit I've provided to the csrc-r4k driver
available on MIPS:
https://lkml.org/lkml/2020/5/11/576

To cut it short, you are right. The solution with using clocksource_mark_unstable()
is better alternative spied up in x86 tsc implementation. I'll use a similar
approach here and submit the updated patch in v3.

Could you please proceed with the rest of the series review? I'd like to send
the next version with as many comments taken into account as possible. The
patchset has been submitted a while ago, but except Rob noone have had any
comments.(

-Sergey