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

Powered by blists - more mailing lists