Path: news.mitre.org!blanket.mitre.org!nntprelay.mathworks.com!newsfeed.gte.net!news.he.net!newshub.cts.com!newsfeed.cts.com!cmkrnl!jeh
From: jeh@cmkrnl.com (Jamie Hanrahan)
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: KeInsertQueueDpc bug on SMP systems?
Message-ID: <1998Jan22.134333.8433@cmkrnl>
Date: 22 Jan 98 13:43:33 PST
References: <69lhm3$q2r$1@decius.ultra.net> <69od14$ptg@news.microsoft.com>  <34c7a559.19655531@news.alt.net>
Organization: Kernel Mode Systems, San Diego, CA
Lines: 61

In article <34c7a559.19655531@news.alt.net>, tony@ercolano.com 
(Anthony V. Ercolano) writes:
> johns@chiark.greenend.org.uk (John Sullivan) wrote:
>>My interpretation of the KeInsertQueueDpc call is that a single DPC
>>object may be queued only once. Re-queueing the same object is
>>expected to be a no-op returning FALSE, however this does not (to me!)
>>indicate that you are expected to actually try to re-queue the same
>>DPC twice.
> 
> Your interpretation of the API is is defficient.  You are of course
> expected to be able to queue the DPC MORE THAN ONCE.  This is how it
> is designed.  It is expected that an ISR can and will call insertqueue
> with the same dpc.  It is very possible and the driver writer must
> deal with the fact that the ISR might be reinvoked before the DPC
> queue is emptied.  

Um, perhaps your interpretation of the problem is a bit too sweeping, 
for this STILL WORKS without a problem.  

If you call KeInsertQueueDpc when the DPC object is already safely on 
the queue (when its Lock field is non-NULL) there is no problem.  

You can do this as many times as you like, and there's still no
problem. 

The problem only occurs when two different processors try to enqueue
the same not-queued DPC object at very close to the same time. 
And frankly, this just isn't going to happen very often.  

Why?  Well, DPCs are usually queued from ISRs; the DPC objects are
usually instantiated on a per-device basis, as are the interrupt
objects.  If you've set up the interrupt object and its spinlock
correctly (and you have to work some to get it wrong), you can't have
the same ISR on behalf of the same context (device, etc.) running at
the same time on multiple CPUs; if the interrupt tries to occur while
you're already in the ISR, the call to the second instance of the ISR
will be stalled behind the interrupt object spinlock until the first
instance returns to caller. 

The problem could come up in drivers where either:

1) You have two more interrupts per device, the ISRs use a common DPC
object, and you failed to provide a common interrupt object spinlock
for all of the device's interrupts. Then two instances of the ISR can
run at the same time on an MP system. 

2) You have two or more interrupting devices, each with its own 
interrupt object spinlock, but for some bizarre reason both ISRs are 
trying to queue the same DPC object.  

Both of these are obviously design problems (the driver's, not NT's):
You're trying to access the same data (the DPC object) from two
different spinlock ownership contexts, and you will likely have many 
other headaches besides the KeIQDpc behavior. 

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
        Internet: jeh@cmkrnl.com (JH645)  CompuServe: 74140,2055  
drivers, internals, networks, applications, and training for VMS and Windows NT
NT driver FAQ, links, and other information:  http://www.cmkrnl.com/

If you post a reply in news, please don't e-mail it too.