linux-kernel - is minimum udelay() not respected in preemptible SMP kernel-2.6.23?

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: <200711071921.52330.mitov@issp.bas.bg>
Date:	Wed, 7 Nov 2007 19:21:52 +0200
From:	Marin Mitov <mitov@...p.bas.bg>
To:	linux-kernel@...r.kernel.org
Subject: is minimum udelay() not respected in preemptible SMP kernel-2.6.23?

Hi all,

I have written a linux device driver for a frame grabber I use in my 
every day experimental work.

In my device driver I have to write to a MMIO register, wait for a while 
(using udelay(65)) for data being written to an internal register (i2c?)
and test a flag (in another MMIO register) if the operation has completed. 
(The hardware guarantees that the operation has completed in less than 
65 usec). If the flag is not reset I write a message via printk.
After switching to the kernel-2.6.23 (compiled as PREEMPTIBLE SMP i686)
(AMD dual core) I see this message in dmesg output sometime.

Testing with rdtscll() before and after udelay(65) shows the expected
delay of 65 usec (after dividing by CPU frequency) when all is OK, but
gives a big value (in the tenths msec range) when the error message 
shows itself in dmesg. 

Bracketing udelay(65) by:

local_irq_disable();
udelay(65);
local_irq_enable();

as well as by

preempt_disable();
udelay(65); 
preempt_enable();

leads to message disappearing.

I believe the hardware is working correctly, so if the flag is not reset 
I think udelay(65) returns prematurely (the flag clears some time latter)
And it does not matter if I use udelay(65) or udelay(100).

What could be the reason for such a behavior?
Is this a bug in udelay() due to preemption?
(udelay() being preempted and migrated to another processor)

All my previous kernels used were SMP (but not PREEMPTIBLE)

My kernel is compiled with:
CONFIG_PREEMPT=y
CONFIG_IRQBALANCE=y
CONFIG_HPET_TIMER=y

And I have this line in dmesg:
Time: acpi_pm clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1

The south bridge is: VIA VT8237 (Asus A8V Delux)

Thank you in advance for your help in understanding  where
the problem is coming from.

Best regards.

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