linux-kernel - Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix pyaudio (and probably more)

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:	Sun, 4 Jan 2015 21:15:55 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Pavel Machek <pavel@....cz>,
	Marc Zyngier <marc.zyngier@....com>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix
 pyaudio (and probably more)

On Sun, Jan 04, 2015 at 12:57:09PM -0800, Linus Torvalds wrote:
> On Sun, Jan 4, 2015 at 12:45 PM, Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
> >
> > Because we're discussing a choice between two evils.
> 
> .. and Pavel pointed you to several screenfuls of google hits for
> people complaining about this.
> 
> End of discussion. Seriously. Your whinging about "support costs" is
> just crying over the fact that you have users. Deal with it.

No, it is not the end of discussion, because what you've done is /really/
equally bad as what Nico was suggesting.  In fact, it /could/ be worse.

Yes, x86 has the bogomips thing, and it switched to using a TSC.  I'm
willing to bet that on x86, the reported bogomips value is pretty similar
whether it's using the TSC or whether it's using a software timing loop.

This is not the case on ARM.  Here's an example where we use a hardware
timer for the delay loop:

Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=12000)

which is nowhere near the precision of the CPU clock rate.  So, when
we have a hardware timer based delay implementation, the bogomips
value which the kernel has access to (and thus the loops_per_jiffy
value) is totally ... bogus.

If we want to take note of the "screenfulls of users reporting problems"
then we need a much better solution than a simple revert, because right
now, the simple revert makes machines with GHz clock frequencies look
slower than the old 1990s 26-bit ARM technology.

So, Nico's NAK for a simple revert was the _right_ response, even if the
remainder was not correct.

Now, Pavel is the /first/ to report this regression to the ARM kernel
community.  Yes, it may be that other users found a problem and failed
to report it (which seems to be a /very/ common problem.)  Thanks to
Pavel, we're now aware of it, and now we need to fix it properly, not
via some bastardized and broken revert by someone who doesn't know
the implications of that.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/