linux-kernel - Re: [RFC] Improving udelay/ndelay on platforms where that is possible

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:   Thu, 16 Nov 2017 12:00:01 -0500 (EST)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Marc Gonzalez <marc_gonzalez@...madesigns.com>
cc:     Russell King - ARM Linux <linux@...linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        John Stultz <john.stultz@...aro.org>,
        Douglas Anderson <dianders@...omium.org>,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will.deacon@....com>,
        Jonathan Austin <jonathan.austin@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Kevin Hilman <khilman@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Thibaud Cornic <thibaud_cornic@...madesigns.com>,
        Mason <slash.tmp@...e.fr>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is
 possible

On Thu, 16 Nov 2017, Marc Gonzalez wrote:

> On 16/11/2017 17:47, Nicolas Pitre wrote:
> 
> > Look at cpufreq_callback() in arch/arm/kernel/smp.c.
> 
> Are you pointing at the scaling of loops_per_jiffy done in that function?
> 
> As I wrote earlier:
> 
> If I'm reading arch/arm/kernel/smp.c correctly, loops_per_jiffy is scaled
> when the frequency changes.
> 
> But arch/arm/lib/delay-loop.S starts by loading the current value of
> loops_per_jiffy, computes the number of times to loop, and then loops.
> If the frequency increases when the core is in __loop_delay, the
> delay will be much shorter than requested.

The callback is invoked with CPUFREQ_PRECHANGE before the actual 
frequency increase. If your CPU clock is per core, then you won't be in 
the middle of the delay loop when this happens, unless you change your 
core clock from an interrupt handler.

If your CPU clock is common to all cores then you are screwed. In that 
case the only way out is a hardware timer based delay.


Nicolas