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]

Message-ID: <CA+55aFyRE0Sm3NFtY7cz8p=ZFK5WQDo-oNUHGW99+EQGr_rigA@mail.gmail.com>
Date:   Tue, 31 Oct 2017 10:58:19 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
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 10:45 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So I'm very much open to udelay improvements, and if somebody sends
> patches for particular platforms to do particularly well on that
> platform, I think we should merge them. But ...

Side note: this is obviously a negative feedback circle, where because
we know we can't do all that great in general, few platforms really
bother to do as well as they perhaps could, since nobody should
generally care that deeply due to the generic problem..

Again, if a driver that has tight timing requirements can just
generate the timings from its own hardware, that tends to
JustWorks(tm).

It was what people used to do traditionally at least on the PC/AT
platform. None of this "udelay()" crud, you knew that doing a single
PIO read took one usec, so you'd just delay that way. Then the
hardware moved from ISA to EISA, and everything sped up, but that was
ok, because now it needed a shorter delay anyway...

Doing things like a status register read is often a good way
(sometimes the _only_ way) to make sure preceding writes have been
flushed all the way to the device anyway, so it can have those kinds
of incidental advantages.

Of course, all of this is relevant only for delays on the scale of
individual device accesses. But that's also when udelay/ndelay() tends
to have the most problems.

               Linus