<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: cipe-win32-pre9 fix
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Thu, 10 May 2001 22:45:09 +0200
In-reply-to: <31276.988416041@www32.gmx.net>

Yeah. That's the bit that I read in the first place. And I put spinlocks in
EVERYTHING. Just before you got involved, I changed the way I used memory
to solve a very vexing set of problems. What made it harder to solve these
problems was the fact that, due to some interaction that I don't
understand, the spinlocks made the driver crash with INVALID_IRQL. That was
back in pre5 or pre6. I currently don't see why I should put them back in
but I'm open to proof that they are needed, i.e. showing that the driver
structure allows the (unprotected ?) data structures to be corrupted by
concurrent access by different threads. Remember, we are not in danger of
simultaneous accesses from via different TAP devices, because the data
structures are not shared between devices.

No, you're not being a wise guy at all, it's just that you're taking the
road that I spent a great deal of time cutting out of the undergrowth  and
I don't want us to rush out and reimplement all of my old bugs. I started
out with an elegant design at first but had to make a whole lot of
concessions to vagaries of Win32 device drivers. We currently have a
working, stable device driver but breaking the code is a lot easier than
you might think.

I'm just content to reach perfection a little slower than you :-)

DKW

On Thursday, May 10, 2001 at 16:34:56 [ADT] Erik Wallin wrote:
> 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
> to
> > invalid irql. The documentation implies (Microsoft docs, go figure)
> that
> > the spinlocks should only REALLY be needed on SMP hardware. Please read
> the
> > TODO.TXT to find out what I think are the issues.
> 
> I looked up syncronization in the documentation I have. This is what I
> found.
> 
> 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 this.
> 
> I'll just keep on reading the docs until I understand this.
> 
> /Erik
> 
> 
> 
> 
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Damion Wilson wrote:
> <blockquote TYPE=CITE>No. Wait. Stop. The spinlock stuff causes problems
> in the list management.
> <br>I just finished yanking it all out because it was causing crashes due
> to
> <br>invalid irql. The documentation implies (Microsoft docs, go figure)
> that
> <br>the spinlocks should only REALLY be needed on SMP hardware. Please
> read the
> <br>TODO.TXT to find out what I think are the issues.</blockquote>
> I looked up syncronization in the documentation I have. This is what I
> found.
> <p>Windows 2000 DDK, Network Drivers, Design Guide, 3.4, Spin Locks:
> <blockquote><i>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.</i>
> <br><i>...</i>
> <br><i>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.</i></blockquote>
> Doesn't this apply to our case?
> <p>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
> this.
> <p>I'll just keep on reading the docs until I understand this.
> <p>/Erik
> <br>&nbsp;
> <blockquote>&nbsp;</blockquote>
> </html>
> 





<< | Thread Index | >> ]    [ << | Date Index | >> ]