Well wait now. NDIS protects against your code segment getting yanked out from under you, as long as you use NDIS’s work item, timer, and DPC support. That’s not the real issue. The real issue is that your callback tries to use some pool memory (or other allocated resource) that your cleanup routine has already free’d. NDIS can’t protect against that.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, February 17, 2010 3:22 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Dpcs and Synchronisation
This scenario is even more likely when using NDIS Work Item support.
Since the work item is also PASSIVE, even more of a chance exists for the driver to complete the unload and unmap before the worker thread exits the driver code scope.
Cheers,
Dave Cattley
From: “Doron Holan”
Sent: Wednesday, February 17, 2010 6:11 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Dpcs and Synchronisation
> How do you know that it can never be hit upon? That is na?ve to think
> that just b/c something is running at passive on one processor and
> dispatch on another proc that a timing window is eliminated. I have
> certainly debugged many a crash dump where exactly this scenario has happened.
>
> d
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
> Morreale
> Sent: Wednesday, February 17, 2010 3:06 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Dpcs and Synchronisation
>
> On Wed, 2010-02-17 at 19:30 +0000, Doron Holan wrote:
>> You will get an pause/halt (these are NDIS specific concepts, but
>> they map to the more generic lifetime model) before unload, but that
>> doesn’t really matter. The window exists if you wait for dpc rundown
>> in your current schecme in unload or in halt/pause
>>
>
> MiniportPause runs at PASSIVE. Yes, there is a window, but no, it can
> never be hit upon.
>
> The idea to flush all outstanding queued DPCs, by each driver (using
> such) during a shutdown, is an interesting architectural decision.
>
> Thx,
> -PWM
>
>> d
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
>> Morreale
>> Sent: Wednesday, February 17, 2010 11:26 AM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] Dpcs and Synchronisation
>>
>> On Wed, 2010-02-17 at 17:38 +0000, Doron Holan wrote:
>> > You set the event, your wait is now satisfied and the stack unwinds.
>> > The DPC which has set the event has not yet returned from
>> > KeSetEvent or has not yet unwound back to the kernel. Since your
>> > wait is satisfied, your driver now unloads but the DPC stack still has not yet unwound.
>> > When the DPC stack unwinds, it now executes unmapped code. Boom.
>> > Flushing DPCs solves this problem by making sure the DPC stack unwinds.
>> >
>> > d
>>
>>
>> I completely understand (and did prior) what you are saying wrt
>> routine termination.
>>
>> What I don’t understand, is whether you are telling me that there are
>> cases where, after driver entry, I will get a Restart/Unload without
>> an intervening Pause and/or Halt.
>>
>> Thanks,
>> -PWM
>>
>>
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W.
>> > Morreale
>> > Sent: Wednesday, February 17, 2010 9:33 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] Dpcs and Synchronisation
>> >
>> > On Wed, 2010-02-17 at 17:18 +0000, Doron Holan wrote:
>> > > Which means unload can proceed, unmap the image and the ret
>> > > instruction from your dpc has yet to execute and then you bugcheck.
>> > > Flush your dpcs and this goes away.
>> > >
>> > > d
>> >
>> >
>> > I’m waiting in pause/halt/unload. You best not remove my text
>> > while I’m still alive.
>> >
>> > Thx
>> > -PWM
>> >
>> >
>> > >
>> > > tiny phone keyboard + fat thumbs = you do the muth
>> > >
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Peter W. Morreale
>> > > Sent: Wednesday, February 17, 2010 9:02 AM
>> > > To: Windows System Software Devs Interest List
>> > >
>> > > Subject: Re: [ntdev] Dpcs and Synchronisation
>> > >
>> > >
>> > > On Wed, 2010-02-17 at 10:57 -0500, Mark Roddy wrote:
>> > > > Um, aren’t you still in the dpc when the count goes to zero?
>> > >
>> > > Yes. The last executable code in the DPC would be to set the event.
>> > >
>> > > -PWM
>> > >
>> > > >
>> > > >
>> > > > On Wednesday, February 17, 2010, Peter W. Morreale
>> > > > wrote:
>> > > > > On Wed, 2010-02-17 at 20:05 +1100, James Harper wrote:
>> > > > >> I have never figured this out properly and it’s getting me
>> > > > >> into trouble…
>> > > > >>
>> > > > >> My driver maintains a list of events that are triggered by
>> > > > >> Xen, via my Isr. My child drivers ask to bind to these
>> > > > >> events which could be either as a Dpc, or at DIRQL (where
>> > > > >> they probably create their own Dpcs anyway). The bus driver
>> > > > >> Isr checks to see what type of event is wanted and either
>> > > > >> just calls the service routine directly or schedules a Dpc
>> > > > >> that calls the service routine.
>> > > > >>
>> > > > >> The problem comes at teardown (eg driver unload or hibernation).
>> > > > >> KeRemoveQueueDpc will ensure that the Dpc is no longer
>> > > > >> queued, but how can I be sure that the Dpc is not currently
>> > > > >> being executed?
>> > > > >> KeFlushQeuedDpcs does this, but for all Dpc’s in the system
>> > > > >> which is overkill, and isn’t available under Windows 2000
>> > > > >> either. The latter objection is not really a concern for me
>> > > > >> as my driver doesn’t work under
>> > > > >> 2000 anyway, but I’m hoping that there is a way to ask if
>> > > > >> the Dpc is really completely finished and I can destroy the
>> > > > >> KDPC structure…
>> > > > >>
>> > > > >
>> > > > > I solved this by using a reference counter and an event.
>> > > > > Increment the
>> > > > > reference counter prior to queueing the DPC, then decrement
>> > > > > in the DPC.
>> > > > > When the counter goes to zero, set the event.
>> > > > >
>> > > > > Interested parties wait on the event.
>> > > > >
>> > > > > Ping me if you want to see the code.
>> > > > >
>> > > > > Best,
>> > > > > -PWM
>> > > > >
>> > > > >
>> > > > >> Thanks
>> > > > >>
>> > > > >> James
>> > > > >>
>> > > > >> —
>> > > > >> NTDEV is sponsored by OSR
>> > > > >>
>> > > > >> For our schedule of WDF, WDM, debugging and other seminars
>> > > > >> visit:
>> > > > >> http://www.osr.com/seminars
>> > > > >>
>> > > > >> To unsubscribe, visit the List Server section of OSR Online
>> > > > >> at http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > > >
>> > > > > —
>> > > > > NTDEV is sponsored by OSR
>> > > > >
>> > > > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > > > http://www.osr.com/seminars
>> > > > >
>> > > > > To unsubscribe, visit the List Server section of OSR Online
>> > > > > at http://www.osronline.com/page.cfm?name=ListServer
>> > > > >
>> > > >
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> > >
>> > >
>> > > —
>> > > NTDEV is sponsored by OSR
>> > >
>> > > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > > http://www.osr.com/seminars
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer