In talking with the owner of WDFQUEUE, you cannot unmark a request which
has not yet been marked cancelable. That means that what you are seeing
in the 2nd case is undefined behavior. Furthermore, if you call
WdfRequestMarkCancelable can call your cancel routine before returning,
but only outside the context of a WDFQUEUE callback. That means 2
things
- if you are calling it outside the context of the io event callback,
you cannot call it with a lock held if that lock will also be acquired
by the cancel routine since you can deadlock on the same thread. In
this case you have to
Lock()
Remember request
Unlock()
Mark cancelable
Lock()
Set a field indicating you can unmark cancelable
Unlock()
And then you need the logic in the dpc/timer/completer to look at the
marked cancelable field
- if you are calling it inside the context of the io event callback
you can all mark cancelable with a lock held but you have to make sure
you don’t do that elsewhere in your code where you can deadlock. In
this case you can
Lock()
Remember Request
Mark Cancelable
Unlock()
Obviously 2) is much simpler, but you can’t do it everywhere. We are
discussing how to fix this for the next version so that you can do 2) in
all scenarios.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Friday, May 12, 2006 1:51 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfRequestUnmarkCancelable returns STATUS_CANCELLED if
it hasn’t been marked cancelable
> Is it possible to set up the WDFDEVICE so that it automagically
allocates the all the
> contexts without the explicit ObjectAllocate calls?
You can get KMDF to allocate the first one automatically by calling
WdfDeviceInitSetRequestAttributes(). When you do this, all wdfqueue
presented requests will have that context. If you need more then one
context, you need to allocate them on your own through
WdfObjectAllocateContext(). I’ll take this as a feature
request to be
able to specify more then one context at init time so that they are
all there.
Doron,
Thanks for taking the feature request above for future generations.
Would you please consider another one?
I’ve seen, empirically, that calling WdfRequestUnmarkCancelable() will
return STATUS_CANCELLED if the request has been cancelled (intuitive),
or if WdfRequestMarkCancelable() hasn’t been called (Not so intuitive).
It would simplify life a lot if there was a different return value in
the second case, so a generic completion routine could call the unmark
routine blindly and rely on the return value to decide whether it’s safe
to complete it.
Thanks for your consideration,
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer