The KMDF docs for WdfUsbTargetPipeFormatRequestForWrite state that "Drivers
often divide received I/O requests into smaller requests that they send to an
I/O target, so your driver might create new requests."

Is there a good example somewhere of how to do this safely so that cancels
on the original request propagate to all the child requests? I searched
through the KMDF examples, but I didn't find anything directly relevant.

I know how to do this with WDM IRPs, but I'm new to the KMDF world...

Thanks.

offhand I don't think any KMDF sample demonstrates this, but the basic gist
is to create a linked list of sub requests guarded by a spinlock. the list
entry for each request is in the subrequest's context. when the irp
completes, you pull it out of hte list. on cancellation, you get a request
out of the list, ref it, drop the lock, cancel it, deref it. If you want to
cancel the whole sublist, the content on each subrequest has 2 LIST_ENTRYs.
you lock the list, put each request using the 2nd list entry on a local list
head, ref each request, drop the lock, drain the local list, cancelling each
request, derefing each request. you can only have one thread doing the
cancel the entire list action at a time

d

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Henric" <Henric@discussions.microsoft.com> wrote in message
news:8E9F3507-F97C-435F-8BDF-1C75D87A4E1C@microsoft.com...

Doron,
Can you explain why we should have only one thread to cancel the entire
subrequest list?

Thanks a lot!

Doron Holan [MS] дµÀ:

b/c you need to guard access to the 2nd list entyr in the request context.
if multiple threads are canceling at the same time, the 2nd list entyr which
is used to drain to the local list can be corrupted since 2 threads can
touch it at the same time.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"hanzhu" <schumi.han@gmail.com> wrote in message
news:O2snj6ZgGHA.4892@TK2MSFTNGP02.phx.gbl...