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: <CA+55aFxRRcSJ5i=EcQ-qqMrz0icn28JKjQuH3xGU65hjpVm9hw@mail.gmail.com>
Date:	Sun, 4 Jan 2015 12:57:09 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Pavel Machek <pavel@....cz>, Marc Zyngier <marc.zyngier@....com>,
	Russell King <rmk+kernel@....linux.org.uk>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix
 pyaudio (and probably more)

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.

I've reverted the change for now, since that's clearly better than
leaving things broken. And you should acknowledge that. In fact, you
should *more* than acknowledge that, you need to internalize it and
*understand* it, instead of arguing.

The fact is, we have bogomips on x86 too, and they've been around for
a hell of a lot longer than ARM has been. The number may not be
"meaningful" any more (since it's TSC cycles rather than anything
else), but it's there in /proc anyway.  We had it through the times
when it fluctuated, and your made-up arguments about how it's a bad
thing are just bogus. It wasn't a big deal, and having a reasonable
value is not a problem.

And no, we don't set it to some "obviously bogus value". That just
makes breakage even more subtle.

You could make it be something that is roughly on the order of the CPU
frequency. It doesn't have to be exact, but from a QoI standpoint, try
to do a reasonable job.

And dammit, I really never *ever* want to hear arguments against
fixing regressions ever again. It really is the #1 rule for the
kernel. There is *no* excuse for that NAK. There is only "sorry".

                            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/