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: <20150106183252.GA32449@arm.com>
Date:	Tue, 6 Jan 2015 18:33:14 +0000
From:	Will Deacon <will.deacon@....com>
To:	Pavel Machek <pavel@....cz>
Cc:	"nicolas.pitre@...aro.org" <nicolas.pitre@...aro.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"rmk+kernel@....linux.org.uk" <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, Jan 04, 2015 at 08:37:24PM +0000, 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.
> 
> Alternatively, just don't touch the bogomips computation. It is not
> that much of maintainance burden. You can probably also get away with
> replacing bogomips with actual cpu frequency.
> 
> Replacing it with 1 is asking for trouble.

Peversely, I think that '1.00' would be the correct value for your libjack
case!

I had a quick look at the code, and it seems to be used to construct a
microsecond-precision timeline for things like:

	ctl->signalled_at = jack_get_microseconds();

Now, jack_get_microseconds() is:

	static inline jack_time_t
	jack_get_microseconds (void)
	{
	        return _jack_get_microseconds ();
	}

_jack_get_microseconds is a pointer that points to this guy:

	jack_time_t
	jack_get_microseconds_from_cycles (void) {
	        return get_cycles() / __jack_cpu_mhz;
	}

where __jack_cpu_mhz is the bogomips read once from /proc/cpuinfo and
get_cycles (on ARM) is this gem:

	static inline cycles_t get_cycles(void)
	{
	       struct timeval tv;
	       gettimeofday (&tv, NULL);

	       return ((cycles_t) tv.tv_sec * 1000000) + tv.tv_usec;
	}

The return value from jack_get_microseconds gets used interchangeably with
real usecond values to do things like find the audio frame at Nus into a
stream, so I don't really see how any of this can work. In this case, we
just need *a* bogomips value to stop the initialisation from failing, then
hope that pyaudio decides not to use jack after all (it falls back to some
alsa thing on my machine)

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