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]
Date:	Tue, 07 Nov 2006 21:06:46 -0500
From:	john cooper <john.cooper@...rd-harmonic.com>
To:	Kevin Hilman <khilman@...sta.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org,
	john cooper <john.cooper@...rd-harmonic.com>
Subject: Re: 2.6.18-rt7: rollover with 32-bit cycles_t

Kevin Hilman wrote:
> On ARM, I'm noticing the 'bug' message from check_critical_timing()
> where two calls to get_cycles() are compared and the 2nd is assumed to
> be >= the first.
> 
> This isn't properly handling the case of rollover which occurs
> relatively often with fast hardware clocks and 32-bit cycle counters.
> 
> Is this really a bug?  If the get_cycles() can be assumed to run between
> 0 and (cycles_t)~0, using the right unsigned math could get a proper
> delta even in the rollover case.  Is this a safe assumption?

I was concerned about that as well back when I was getting the
instrumentation functional on the pxa270 as the rollover could
be as short as ~8s which wasn't really long enough for test
validation.  However there is a /64 prescaler on that ARM core
(and others) which can function as a bandaid and extend the range
to ~8minutes.

I wasn't able to convince myself in a quick read of the code if
roll over was being detected/corrected (though it certainly may).
But even if not the only requirement needed to do so would be to
assure any two consecutive data points logged per CPU were spaced
apart less than the counter's wrap interval.  Given the periodic
events being logged in the normal course of operation this condition
would certainly be met.

-john

-- 
john.cooper@...rd-harmonic.com
-
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