linux-kernel - Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter

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] [day] [month] [year] [list]

Message-ID: <1393988191.5392.8.camel@marge.simpson.net>
Date:	Wed, 05 Mar 2014 03:56:31 +0100
From:	Mike Galbraith <bitbucket@...ine.de>
To:	John Stultz <john.stultz@...aro.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"Cc: Salman Qazi" <sqazi@...gle.com>
Subject: Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in
 cyclecounter_cyc2ns()

On Wed, 2014-03-05 at 08:58 +0800, John Stultz wrote: 
> On Tue, Mar 4, 2014 at 3:10 PM, Mike Galbraith <bitbucket@...ine.de> wrote:
> > On Tue, 2014-03-04 at 14:40 +0800, John Stultz wrote:
> >> On Tue, Mar 4, 2014 at 1:38 PM, Mike Galbraith <bitbucket@...ine.de> wrote:
> >> > (crap crap crap... M.A.I.N.T.A.I.N.E.R.S _dummy_)
> >> >
> >> > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
> >> >
> >> > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock",
> >> > cycles * mult >> shift is overflow prone. so give it the same treatment.
> >> >
> >> > Cc: Salman Qazi <sqazi@...gle.com>
> >> > Cc: John Stultz <john.stultz@...aro.org>,
> >> > Signed-off-by: Mike Galbraith <bitbucket@...ine.de>
> >>
> >> Thanks for sending this in!  Curious exactly how the issue was being
> >> triggered?
> >
> > Dunno that it is.  This is the result of me rummaging around, looking
> > for any excuse what-so-ever for a small and identical group of weird a$$
> > boxen running old 2.6.32 kernels (w. 208 day fix!) to manage to hop back
> > and forth in time by exactly 208 days.  Grep showed me that function, so
> > I scurried off and swiped the fix.
> 
> So.. this makes me a bit more hesitant to really queue this,
> particularly since the timecounter logic is supposed to periodically
> accumulate cycles so you don't run into these overflow issues (the
> earlier fix was for sched_clock which didn't do any accumulation).

Ok.

> So, if you're seeing time jump around, that's probably clocksource or
> timekeping related, and not tied to the cyclecounter code. Do you have
> any other info about these systems? What clocksource are they using,
> etc?

Not much, clocksource is TSC, with CPUs that should make it reliable.
They're interested now, so I'll be hearing more digging more.

-Mike

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