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

> On Wed, Jan 07, 2015 at 03:34:42PM -0500, Nicolas Pitre wrote:
> > On Wed, 7 Jan 2015, Linus Torvalds wrote:
> > 
> > > On Wed, Jan 7, 2015 at 11:00 AM, Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
> > > >
> > > > We'll make sure it is scaled properly so not to have orders of magnitude
> > > > discrepancy whether the timer based or the CPU based loop is used for
> > > > the purpose of making people feel good.
> > > 
> > > Why?
> > > 
> > > You'd basically be lying.  And it might actually hide real problems.
> > > If the scaling hides the fact that the timer source cannot do a good
> > > job at microsecond resolution delays, then it's not just lying, it's
> > > lying in ways that hide real issues. So why should that kind of
> > > behavior be encouraged? The actual *real* unscaled resolution of the
> > > timer is valid and real information.
> > 
> > I think you are missing something fundamental in this thread.
> 
> I think what Linus is trying to tell us is that:
> 
> 1. Where the kernel uses a software loop for implementing delays,
>    the kernel bogomips gives us a calibration of that loop.
> 
> 2. Where the kernel uses a hardware timer for implementing delays,
>    the kernel bogomips gives us a calibration of that hardware timer.
> 
> And it doesn't matter whether or not that timer has anything to do with
> the raw CPU speed.
> 
> In other words, bogomips is a statement about the accuracy of the
> internal kernel mechanism being used for delays, nothing more, nothing
> less.

I'm not clear if that's actually what Linus is trying to tell us.

But that statement makes no sense at all.  Why would user space care 
about kernel internal mechanism for small delays?  This hardly has any 
influence on user space and I just can't imagine any user space code 
consuming the bogomips value for that purpose.

What user space did with bogomips, though, is to get some relative 
measure of the CPU speed for whatever calibration purposes, or simply 
for pretty printing.

> Now, if I understand Linus correctly, what irks him is when someone
> upgrades a kernel on a platform, and some userland breaks.  That's
> something which I've said multiple times I don't have a problem
> agreeing with, and I suspect no one in this thread would disagree
> that this is a serious failing, and one which needs fixing ASAP.

I agree too.  And that is fixed in mainline with commit 4bf9636c39.

> However, if running userland on platform A works, and but it doesn't
> work on platform B.  The breakage may well be due to platform A reporting
> 300 bogomips because it's using the kernel software loop, and platform
> B reporting 6 bogomips because its using a hardware timer, but the CPU
> is actually faster.  However, this is not a kernel problem, and it
> certainly is not a regression.  It's a userspace bug which needs
> userspace to fix.

There I disagree.  In the spirit of "the kernel shall never break user 
space ever" I'd say that the kernel is simply doing a poor job at 
providing user space with a value that won't break user space 
expectations.  And since it is not that hard to do (I made a patch 
already) I'd say we have less to lose by fixing it than keeping a 
totally senseless value around.


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/