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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 Jan 2015 10:47:09 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	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, Jan 7, 2015 at 10:11 AM, Catalin Marinas
<catalin.marinas@....com> wrote:
>
> I think this makes sense since __delay() expects the number of loops
> as argument rather than a duration scaled by some factor (based on the
> generic timer frequency).

Gaah. You guys make no sense at all.

No, __delay() does not expect "number of loops".

It doesn't do that on x86, and it doesn't even do it on arm.

It *literally* does exactly the reverse of what you say it does.

__delay() very much expects a "duration scaled by some factor". The
factor being "loops_per_jiffy" (ok, so it's a "reverse factor", but
you get the idea).

And this is very much exactly why bogomips is that "2 *
loops_per_jiffy * HZ / 1000000".

Let's break it down:

 - "loops_per_jiffy" is just the scale factor for __udelay(). Ignore
the "loops" part of the name, since it's purely historical. It comes
from the original "decrement and jump" implementation, but that hasn't
been true on x86 for over 15 years.

 - the "2x" factor is also purely historical, and comes from the same
"decrement and jump" thing - it used to be two instructions. But
again, it hasn't been true for a *looong* time,  but it is part of the
bogosity of bogomips.

 - the "*HZ" is the "per jiffy" part.

 - the "1000000" is the "MHz" part. The clock had better tick at a
megahertz or more, since the whole point of this is to do "udelay()".

Really. The original commit that removed bogomips from ARM was
*wrong*. Because that

    per_cpu(cpu_data, i).loops_per_jiffy / (500000UL/HZ

calculation is in fact  the very DEFINITION of bogomips (it's just
written in a way to not overflow).

Seriously.

The reason I reverted that commit is because it was crap. When Pavel
made the report, I looked at the code, and immediately reverted it.
For good reason. Exactly because that original patch was WRONG.

The old bogomips computation in arch/arm/kernel/setup.c is exactly the
right thing to do.

And every time somebody thinks it has to be about "loops" or about
"cpu frequency", I can only say "STOP IT". It hasn't been about loops
or CPU frequency for ages. I don't know when we switched it to "wait
for the timer", because it predates my history that starts in early
2002. So it's at *least* 13 years old.

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