Re: cipe-win32-pre9 fix|
Erik Wallin <erikw,AT,sec,DOT,se>|
Thu, 10 May 2001 22:00:27 +0200|
Damion Wilson wrote:
No. Wait. Stop. The spinlock stuff causes problems
in the list management.
I just finished yanking it all out because it was causing crashes due
invalid irql. The documentation implies (Microsoft docs, go figure)
the spinlocks should only REALLY be needed on SMP hardware. Please
TODO.TXT to find out what I think are the issues.
I looked up syncronization in the documentation I have. This is what I
Windows 2000 DDK, Network Drivers, Design Guide, 3.4, Spin Locks:
A spin lock provides a synchronization mechanism for protecting
resources shared by kernel-mode threads running at IRQL > PASSIVE_LEVEL
in either a uniprocessor or a multiprocessor machine.
A typical use for a spin lock is to protect a queue. For example,
the miniport send function, MiniportSend, might queue packets passed to
it by a protocol driver. Because other driver functions also use this queue,
MiniportSend must protect the queue with a spin lock so that only one thread
at a time can manipulate the links or contents. MiniportSend acquires the
spin lock, adds the packet to the queue and then releases the spin lock.
Using a spin lock ensures that the thread holding the lock is the only
thread modifying the queue links while the packet is safely added to the
queue. When the NIC driver takes the packets off the queue, such an access
is protected by the same spin lock. When executing instructions that modify
the head of the queue or any of the link fields making up the queue, the
driver must protect the queue with a spin lock.
Doesn't this apply to our case?
I'm not trying to be a wize guy here. It's just that I don't want to
drop this thread :-), until I understand why I don't have to worry about
I'll just keep on reading the docs until I understand this.