A pointer to the FLT_CALLBACK_DATA structure will be passed as a
parameter to the FLT_DEFERRED_IO_WORKITEM_ROUTINE:
typedef VOID
(FLTAPI *PFLT_DEFERRED_IO_WORKITEM_ROUTINE) (
__in PFLT_DEFERRED_IO_WORKITEM FltWorkItem,
__in PFLT_CALLBACK_DATA CallbackData,
__in_opt PVOID Context
);
This is the same FLT_CALLBACK_DATA that you pass in the call to:
__checkReturn
__drv_maxIRQL(DISPATCH_LEVEL)
NTSTATUS
FLTAPI
FltQueueDeferredIoWorkItem (
__in PFLT_DEFERRED_IO_WORKITEM FltWorkItem,
__in PFLT_CALLBACK_DATA Data,
__in PFLT_DEFERRED_IO_WORKITEM_ROUTINE WorkerRoutine,
__in WORK_QUEUE_TYPE QueueType,
__in PVOID Context
);
Since you have pended this I/O operation, completion processing is
suspended and hence the FLT_CALLBACK_DATA structure will be valid when
your FLT_DEFERRED_IO_WORKITEM_ROUTINE is called.
All other information that you need should be passed to the
FLT_DEFERRED_IO_WORKITEM_ROUTINE through the Context parameter. If you
are using any ref-counted structures then those need to be correctly
referenced as Petr pointed out.
Regards,
Sarosh.
File System Filter Lead
Microsoft Corp
This posting is provided “AS IS” with no warranties, and confers no Rights
Petr Kurtin wrote:
Hello,
I had the same problem. PFLT_CALLBACK_DATA is created for the actual I/O
request (see FltAllocateCallbackData), so copy all needed variables to your
new location - and I do the same for PFLT_RELATED_OBJECTS structure. Just
don’t forget to call FltObjectReference on copied Instance/Volume pointers
(note this Flt* function can fail) and reference Volume from your workitem
when you’re going to perform any I/O. Reference is needed here, because it
can tell you if the volume is not in teardown process.
You also need to remove all workitem pending requests from the queue when
the volume teardown appears (i.e. InstanceTeardownStart callback and pre-
IRP_MJ_FILE_SYSTEM_CONTROL (FSCTL_DISMOUNT_VOLUME) callback).
Petr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 28. bøezna 2009 9:21
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter Objects and Callback Data structures passed in
post-operation callback
Hi,
I need to do the following in my filter driver:
In the post operation callback routine, I need to create an IO work item and
perform my tasks in the worker routine. MSDN states the following:
A minifilter driver can use FltQueueDeferredIoWorkItem in a post-operation
callback (PFLT_POST_OPERATION_CALLBACK) routine as follows:
- The post-operation callback calls FltAllocateDeferredIoWorkItem to
allocate the work item.
- The post-operation callback calls FltQueueDeferredIoWorkItem to post
the operation to the work queue.
- The post-operation callback returns
FLT_POSTOP_MORE_PROCESSING_REQUIRED.
- After processing the I/O operation, the work routine calls
FltCompletePendedPostOperation to return the I/O operation to the Filter
Manager.
I need to use the callback structure (PFLT_CALLBACK_DATA) and the Filter
Objects (CFLT_RELATED_OBJECTS) structure passed to the post operation
callback routine in my worker routine. Do I need to create copies of both
these structures and pass them to the worker routine? Are these structures
local on the stack of the calling routine, causing them to disappear when I
return with FLT_POSTOP_MORE_PROCESSING_REQUIRED? Any help/pointers here will
be appreciated.
Thanks,
Sonia
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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