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]

Message-ID: <alpine.LFD.2.11.1501071914250.1322@knanqh.ubzr>
Date:	Wed, 7 Jan 2015 19:45:47 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Catalin Marinas <catalin.marinas@....com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	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 Wed, 7 Jan 2015, Linus Torvalds wrote:

> In this case, pretty much all of /proc/cpuinfo is mainly
> "informational". Maybe there are applications that show it, but more
> likely you have people who ssh in and just do
> 
>     cat /proc/cpuinfo
> 
> to see what kind of system they are running on. That's the main point
> of much of /proc, and things like /proc/cpuinfo in particular.

Would you mind if on ARM we used the bogomips line as an informative 
approximation for the CPU speed?  After all, this is the meaning it had 
for nearly 20 years.  And unlike on X86 we don't have the actual CPU 
clock in there.  And that's still the meaning it has on most ARM systems 
out there.

> Changing the bogomips value - even radically - or removing it entirely
> isn't a regression in itself.
> 
> And in this case, I do suspect that the *actual* value really almost
> doesn't matter. It looks more like some internal badly done hint for
> some buffer size or other. It is possible that wild fluctuations could
> be noticeable, but it's fairly unlikely.

In that case nobody would complain if on some systems we make it back to 
the traditional value.  It took over a year before problem report about 
its disappearance reached us.

On other systems it will remain the same because its meaning still 
hasn't changed.  But on the whole it'll have a coherent meaning.

> The other "good news" in this area is that I suspect that the random
> ARM platforms that actually changed 2.5 years ago are not very widely
> used any more.

I beg to differ.  My primary test platform is one of them and it has the 
latest incarnation of the ARM 32-bit CPU architecture.

Rather, the good news is that not that many user space things rely on 
the bogomips value.  Or maybe people don't upgrade their kernels that 
often e.g. the latest OpenWRT stable version from 3 months ago ships 
with a 3.10 kernel.  Oh and all the Ubuntu releases for ARM in the last 
year shipped with kernels that don't advertise the bogomips and passed 
QA.  So if we bring it back now, better make it usefully informative at 
least for humans.

Nicolas
--
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/