linux-kernel - Re: 2.6.18-rt7: rollover with 32-bit cycles

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: <4551DBA0.6080305@third-harmonic.com>
Date:	Wed, 08 Nov 2006 08:29:04 -0500
From:	john cooper <john.cooper@...rd-harmonic.com>
To:	dwalker@...sta.com
CC:	Kevin Hilman <khilman@...sta.com>, 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

Daniel Walker wrote:

> Seems like the check should really be using something like time_before()
> time_after() which takes the rollover into account .. What I don't
> understand is why we don't see those on x86 ..

Probably due to the fact it is a 64-bit counter.  Even with
a free running rate of 10Ghz it would take nearly 60 years
to wrap.

On PPC and ARM 32-bit counters seems to be common which limits
range unless a prescaler is available.  The better solution is
to detect wrap as a prescaled 32 bit measurement will eventually
run out of usable resolution as core frequency increases.  That is
assuming 64-bit counters don't eventually show up in these
architectures.

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