linux-kernel - Re: Unexpected clocksource overflow in nsec conversion

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: <20120115151403.GB7474@mudshark.cambridge.arm.com>
Date:	Sun, 15 Jan 2012 15:14:03 +0000
From:	Will Deacon <will.deacon@....com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Unexpected clocksource overflow in nsec conversion

On Fri, Jan 13, 2012 at 07:49:51PM +0000, John Stultz wrote:
> On Fri, 2012-01-13 at 16:21 +0000, Will Deacon wrote:
> > I'm having some problems with sched_clock where I experience unexpected
> > overflow due to clocksource->mult being set too high for the width of my
> > clocksource.
> > 
> > My clocksource parameters are:
> > 
> > 	Frequency:	100Mhz
> > 	Width:		56 bits (i.e. mask of (1 << 56) - 1)
> > 
> > 	[ following calculated by clocks_calc_mult_shift ]
> > 	Shift:		24
> > 	Mult:		0x0a000000 (167772160)
> 
> 
> Sigh. Yea. In the past, occasional sched_clock rollovers weren't an
> issue, the idea was it was an potentially unreliable clock, but really
> fast, and any errors would be fleeting. But over time sched_clock's
> requirement have grown.
> 
> I think you probably need to split the sched clock mult/shift pair from
> the clocksource, as they really have different requirements.  The
> clocksource needs to have a larger shift value, so we can make fine
> grained adjustments to keep accurate time, where as sched_clock should
> have a low shift value to avoid frequent overflows.

Ah, ok then. The hardware counter I'm using is guaranteed not to roll over
within 40 years, so I'm happy to ignore hardware overflow at the moment. So
if I avoid using clocksource_cyc2ns from sched_clock then I can also avoid
the large multiplier.

> > So, should we update the clocksource mask when forcing the maximum period
> > to 600 seconds, or am I missing something?
> 
> No. The logic about is really focused around timekeeping requirements,
> not sched_clock. With timekeeping we periodicially accumulate time,
> creating a new cycle_last base from which we generate cycle deltas with.
> This keeps the cycle portion that is multiplied small.

Right - as long as the timekeeping stuff only uses periods of up to 10
minutes then we're safe (rather than looking at the clocksource mask,
for example).

> Again, sched_clock doesn't accumulate, so when the counter gets large
> enough, the multiply can overflow. On x86 we've split the multiply to
> avoid this for now, but this doesn't help on other architectures where
> the counter overflows.

Given that the CPU I'm working with has hardware integer division, I guess I
could just return ticks * (NSEC_PER_SEC / freq) in my sched clock and forget
about the scaling maths?

Cheers,

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/