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:   Tue, 31 Oct 2017 16:56:29 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Marc Gonzalez <marc_gonzalez@...madesigns.com>,
        Mark Rutland <mark.rutland@....com>, Mason <slash.tmp@...e.fr>,
        Jonathan Austin <jonathan.austin@....com>,
        Arnd Bergmann <arnd@...db.de>, Nicolas Pitre <nico@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Michael Turquette <mturquette@...libre.com>,
        Kevin Hilman <khilman@...nel.org>,
        Will Deacon <will.deacon@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Douglas Anderson <dianders@...omium.org>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] Improving udelay/ndelay on platforms where that is possible

On Tue, Oct 31, 2017 at 09:44:20AM -0700, Linus Torvalds wrote:
> On Tue, Oct 31, 2017 at 9:15 AM, Marc Gonzalez
> <marc_gonzalez@...madesigns.com> wrote:
> >
> > On arm32, it is possible to set up udelay() to be clock-based.
> 
> I'm not sure why this is discussed as some kind of generic problem.

Hi Linus,

Marc is stating something that's incorrect there.  On ARM32, we don't
have a TSC, and we aren't guaranteed to have a timer usable for delays.
Where there is a suitable timer, it can be used for delays.

However, where there isn't a timer, we fall back to using the software
loop, and that's where the problem lies.  For example, some platforms
have a relatively slow timer (32kHz).

This centres around is the discussion we had previously:

  http://lists.openwall.net/linux-kernel/2011/01/12/372

where errors of 5% are very much in the "don't care" category for
udelay() - so if udelay() returns early by 5%, we don't care.

Marc, however, does want to care about udelay() etc returning early,
because he wants his NAND driver to be performant, despite using
udelay()/ndelay() in critical paths.  So his argument is that udelay()
and ndelay() should be accurate, and certainly not return early.

Marc's motivation here is to try and force me to "fix" the ARM and
generic loops_per_jiffy code so that these functions provide accurate
delays.  I've said no, based on what we discussed back in 2011.

There's the issue too of the timer-based delay code possibly returning
one timer tick early, which at reasonable timer resolutions is pretty
small.  I don't want to do that, as it encourages people to use data-
sheet values in udelay() and ndelay() without any cushioning, and so
the drivers end up breaking if we fall back to using the software loop
delays - which we know for a fact will return early.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up