Trying to defer some work in create pre-op, and then will reuse some of this for create post-op.
I read the following guidance:
“A minifilter driver that must pend all (or most) incoming I/O operations should not use routines such as FltQueueDeferredIoWorkItem to pend operations, because calling this routine can cause the system work queues to be flooded. Instead, such a minifilter driver should use a cancel-safe queue. For more information about using cancel-safe queues, see FltCbdqInitialize.”
Ok, fine, I was going away from FltQueueDeferredIoWorkItem anyways as I started to write the teardown code and discovered I had no good way to cleanup pending IO.
So now I have an implementation using cancel safe queues i.e. FltCbdqInitialize.
Microsoft’s reference example has me slightly confused: https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys/miniFilter/cancelSafe/cancelSafe.c
In their InsertIo method implementation they create and queue a generic work item using FltAllocateGenericWorkItem(), and FltQueueGenericWorkItem().
Does this design not fall over to the same shortcomings of using FltAllocateDeferredIoWorkItem(), FltQueueDeferredIoWorkItem()?
I’m thinking I should create my own thread via PsCreateSystemThread() and manage my own synchronization. Is using the generic work item queue preferable to this?
Thanks.
In general, yes, they both use the same underlying approach of system
threads and queues. The “deferred” queues have some additional checks
and support for specifically processing a minifilter request, hence the
name … you are deferring the processing of a minifilter request.
Generic work queues are just that, for processing of generic requests
not necessarily minifilter requests.
You can use a generic work item to process a minifilter request but you
lose the checks implemented in the “deferred” API set. That said, I have
always been in the habit of rolling up my own worker subsystem for
processing requests which require it.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 10/25/2016 12:03:34 PM
Subject: [ntfsd] File MiniFilter Deferred Processing using Callback Data
Queues
>Trying to defer some work in create pre-op, and then will reuse some of
>this for create post-op.
>
>I read the following guidance:
>“A minifilter driver that must pend all (or most) incoming I/O
>operations should not use routines such as FltQueueDeferredIoWorkItem
>to pend operations, because calling this routine can cause the system
>work queues to be flooded. Instead, such a minifilter driver should use
>a cancel-safe queue. For more information about using cancel-safe
>queues, see FltCbdqInitialize.”
>
>Ok, fine, I was going away from FltQueueDeferredIoWorkItem anyways as I
>started to write the teardown code and discovered I had no good way to
>cleanup pending IO.
>
>So now I have an implementation using cancel safe queues i.e.
>FltCbdqInitialize.
>
>Microsoft’s reference example has me slightly confused:
>https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys/miniFilter/cancelSafe/cancelSafe.c
>
>In their InsertIo method implementation they create and queue a generic
>work item using FltAllocateGenericWorkItem(), and
>FltQueueGenericWorkItem().
>
>Does this design not fall over to the same shortcomings of using
>FltAllocateDeferredIoWorkItem(), FltQueueDeferredIoWorkItem()?
>
>I’m thinking I should create my own thread via PsCreateSystemThread()
>and manage my own synchronization. Is using the generic work item queue
>preferable to this?
>
>Thanks.
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>
So in summary, moving from using the deferred queues to Callback Data Queues is the right approach to avoid flooding the system queues; and my implementation should include my own worker subsystem.
This is what I suspected, but the reference example implementation just threw me off a bit. I have to give credit to the cancel safe queue example in that it did show a way to use cbdqs, it just wasn’t the best implementation for my use case.
Thanks for your response!