linux-kernel - Re: [BUG] 2.6.37-rc3 massive interactivity regression on ARM

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: <20101208125548.GA9777@n2100.arm.linux.org.uk>
Date:	Wed, 8 Dec 2010 12:55:48 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Mikael Pettersson <mikpe@...uu.se>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	John Stultz <johnstul@...ibm.com>
Subject: Re: [BUG] 2.6.37-rc3 massive interactivity regression on ARM

On Wed, Dec 08, 2010 at 01:40:15PM +0100, Peter Zijlstra wrote:
> On Sun, 2010-12-05 at 16:21 +0000, Russell King - ARM Linux wrote:
> 
> > I'm not sure that's the correct fix - it looks like sched_clock_cpu()
> > should already be preventing scheduler clock time going backwards.
> > 
> > Hmm. IOP32x seems to have a 32-bit timer clocked at 200MHz.  That means
> > it wraps once every 21s.  However, we have that converted to ns by an
> > unknown multiplier and shift.  It seems that those are chosen to
> > guarantee that we will cover only 4s without wrapping in the clocksource
> > conversion.  Maybe that's not sufficient?
> > 
> > Could you try looking into sched_clock_cpu(), sched_clock_local() and
> > sched_clock() to see whether anything odd stands out?
> 
> # git grep HAVE_UNSTABLE_SCHED_CLOCK arch/arm | wc -l
> 0

Hmm, you're right.  In which case it's purely down to sched_clock()
only being able to cover 4s - which seems to be far too small a gap.

I'm not sure that the unstable sched clock stuff makes much sense to
be enabled - we don't have an unstable clock, we just don't have the
required number of bits for the scheduler to work correctly.

Nevertheless, this provides a good way to find this kind of wrap bug.
Even with cnt_32_to_63, we still don't get a 64-bit sched_clock(), so
this bug will still be there.  Even with a 64-bit clock, the bug will
still be there.  It's basically crap code.

Maybe it's better that on ARM, we just don't implement sched_clock()
at all?
--
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/