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.1501041547050.18844@knanqh.ubzr>
Date:	Sun, 4 Jan 2015 15:56:06 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Pavel Machek <pavel@....cz>
cc:	marc.zyngier@....com, rmk+kernel@....linux.org.uk,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix
 pyaudio (and probably more)

On Sun, 4 Jan 2015, Pavel Machek wrote:

> On Sun 2015-01-04 15:25:02, Nicolas Pitre wrote:
> > On Sun, 4 Jan 2015, Pavel Machek wrote:
> > 
> > > On Sun 2015-01-04 15:03:02, Nicolas Pitre wrote:
> > > > If that is still unacceptable to you for whatever reason, then the least 
> > > > wrong compromize should be:
> > > > 
> > > > 	seq_printf(m, "BogoMIPS\t: 1.00\n");
> > > > 
> > > > That'D allow for those broken applications to run while making clear 
> > > > that the provided value is phony. I was about to suggest 0.00 but that 
> > > > could trigger a divide by zero error somewhere I suppose.
> > > 
> > > I don't know what 1.00 will cause, and neither do you, so what about
> > > simply reverting the bad patch?
> > 
> > Because the patch wasn't "bad".  It did solve a recurring support 
> > problem where people did actually complain on the list because the value 
> > was not what they would have liked.  Removing this meaningless value did 
> > actually fix that support issue as no more complaints came through for 
> > the last 1.3 year, and is actually the only way for user space to be 
> > fixed too.
> 
> People complain on the list, so what? People complain about systemd,
> too. We ignore them.

Are you kidding? By that measure, maybe we should ignore you, too?

> Alternatively, just don't touch the bogomips computation. It is not
> that much of maintainance burden.

It causes problems to those applications actually taking that value for 
granted when it is wrong.  This wasn't removed for fun, but rather 
because it caused other kind of troubles by being there.

> You can probably also get away with
> replacing bogomips with actual cpu frequency.

Where do you get that CPU frequency from?  If it was that easy, that's 
what we would have done already.

> Replacing it with 1 is asking for trouble.

What about 100 then?  Or 1000?  Choose your pick.

> See the links I quoted. Removing the value caused real problems. (And
> I still did not hear so much as "sorry".) Now you propose to put
> obviously wrong value in there, and claim it is not a
> problem... because it takes time before someone debugs breakage you
> want to cause.

It wasted a lot of people's time before by simply being there and wrong 
before it was removed.  It's only a matter of whose time you want to 
waste.  Really.


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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ