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-next>] [day] [month] [year] [list]
Message-Id: <201203091437.50996.tvrtko.ursulin@onelan.co.uk>
Date:	Fri, 9 Mar 2012 14:37:50 +0000
From:	Tvrtko Ursulin <tvrtko.ursulin@...lan.co.uk>
To:	x86@...nel.org
Cc:	linux-kernel@...r.kernel.org
Subject: udelay minimum delay guarantee and maximum supported delay?


Hi all,

I was debugging some weird driver behaviour under 3.3.0-rc6+ (amd64) and 
eventually I got to discovering udelay's driver is issuing are occasionally 
short. That results in random hardware behaviour, but that is beside the 
point.

Driver in question wants to delay for 500us at a time, which is not a terribly 
nice thing to do, but putting that aside and talking more in general I would 
have three questions:

1. Are 500us udelays supposed to work? (I know they are not recommended and 
I'll fix that.)
2. Should udelay guarantee it won't delay by less than the time asked?
3. Is ktime_get() considered accurate enough to measure how long udelay 
actually delayed? (Empirical evidence suggests it is, because hardware 
weirdness correlates perfectly with occurences of these short udelays.)

If answers to all are yes then we might have a bug here.

Because I am seeing udelay(500) (_occasionally_) being short, and that by 
delaying for some duration between 0us (yep) and 491us.

As far as I can see this box is using TSC delay and CPU (Intel(R) Core(TM) 
i5-2400S CPU @ 2.50GH) exposes the constant_tsc flag:

 [    1.717050] Refined TSC clocksource calibration: 2494.334 MHz.
 [    1.717054] Switching to clocksource tsc

Am I missing something and what are your opinions?

Thanks,

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