linux-kernel - Re: Use of high-res timers

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: <Pine.LNX.4.44L0.1205311120370.1174-100000@iolanthe.rowland.org>
Date:	Thu, 31 May 2012 11:27:44 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Ingo Molnar <mingo@...hat.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Use of high-res timers

On Thu, 31 May 2012, Thomas Gleixner wrote:

> > Here's an example.  A hardware device accesses a software data
> > structure via DMA, and the driver needs to change the data structure.  
> > However, the data can't be updated safely while the device is using it.
> > Furthermore, we know that the device may continue to access the data
> > for as long as 1 ms after being told to stop (because of internal
> > caches and such).
> 
> And of course the hardware designers decided that there is no need for
> a reliable way to detect that....

Well, it's not quite that bad.  In fact the hardware design does call
for a counter that increments at 8000 Hz; it could be used for this 
purpose.

Except...  In some implementations, the counter stops at unpredictable
times!  It's not reliable; hence this workaround.

> It just depends on the resolution of the underlying clocksource and NTP
> adjustments.
> 
> So the only case where you can run into trouble is when the
> clocksource is coarse grained, e.g. pure jiffies, where two
> consecutive calls can show a 1/HZ delta.
> 
> But you really should not worry much about that, except you are aiming
> for some stoneage platform. Anything up to date is going to have at
> least a 32kHz counter based clocksource. At 32kHz the per clock tick
> increment is ~30us, so that's your expected error.

Just what I needed to know!  Thanks.

Alan Stern

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