There is no race.
When NDIS calls such a function, NDIS has completed everything it is
expecting to do prior to getting called at the NdisXxxxComplete() function.
It is *ready* to be called. It is simply giving the miniport a
(synchronized) opportunity to do what *it* (the miniport) needs to do to
meet the state contract prior to state transition.
The only possible errors are:
- Returning NDIS_STATUS_PENDING and not ever calling the XxxComplete()
function.
- Returning != NDIS_STATUS_PENDING and calling XxxComplete().
- Completing ‘correctly’ but not actually being complete.
But none of those are a ‘race’ between the return from the indication and
calling the completion function.
Cheers,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Sunday, January 17, 2010 6:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MiniportPause races?
MiniportPause() is not special; all other async NDIS requiests have same
behavior and same possibility of race.
And the same outside of NDIS, for all cases where you can return
STATUS_PENDING (which has same value as NDIS_STATUS_PENDING).
At the point where you decide to return STATUS_PENDING, set some
state *atomically* visible to code path that will complete this request
(or atomically insert it into a queue), and just don’t touch the request any
more.
That other path can then preempt your original thread returning
STATUS_PENDING. Originator of the request must prepare to handle this.
Regards,
– pa
“David R. Cattley” wrote in message news:xxxxx@ntdev…
> No, you do not. The only ‘contract’ your driver has with the API is:
>
> -If you return NDIS_STATUS_PENDING, you must call NdisMPauseComplete().
> The order of operations is not specified. Recognize, however, that NDIS
> considers the operation completed when you call NdisMPausComplete().
>
> -If you return != NDIS_STATUS_PENDING, you must not call
> NdisMPauseComplete(). NDIS will do the equivalent of calling
> NdisMPauseComplete() on return from your handler.
>
> Good Luck,
> Dave Cattley
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
> Sent: Saturday, January 16, 2010 4:19 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] MiniportPause races?
>
>
> The documentation for MiniPort pause notes that the routine may return
> NDIS_STATUS_PENDING in the event that the pause conditions are not
> satisfied at the time of the call. In this case the adapter will make a
> call to NdisMPauseComplete() when the adapter is properly quiesced.
>
> What I’m curious about is the possible race if some other thread in the
> driver notes the pending condition, clears it, and calls
> NdisMPauseComplete() while MiniportPause is returning with
> NDIS_STATUS_PENDING.
>
> IOW do I have to ensure that my MiniportPause(NDIS_STATUS_PENDING)
> returns prior to calling NdisMPauseComplete()?
>
> Thanks,
> -PWM
—
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