Hi,
I’m writing an application which scans file operations (a security product, user mode + driver). In order to preserve the OS behavior, I return FLT_PREOP_PENDING / FLT_POSTOP_MORE_PROCESSING_REQUIRED whenever the IRP is asynchronous. This means that if some user mode application requests an asynchronous file operation, the requesting thread will not block. I resume the pre/post operation once I’m done processing the operation, where the resumption is triggered by a user mode thread which completed the scanning.
My problem is that once I call FltCompletePendedPreOperation(), resuming the operation is done in my thread(s), and not in the original thread/process which requested the operation. This means that my user mode thread appears as consuming a lot of CPU, when in fact this CPU should have been attributed to the processes which requested the file operations.
Granted, some of the operations are not called in the original thread context anyway. Still, since I pend and resume the operation, I practically delegate the CPU to my own threads.
My question is:
Is there a ‘natural’, built-in way in the flt manager, to make preop/postop resumption take place in the original process where the IRP initially arrived? Sort of like resuming the operation asynchronously, and where my thread passes the ownership back to where is was before pending.
I thought about creating a worker thread pool and having the resumption take place there, but this would again create a skewed picture where system process is attributed with more CPU than normal. I’m looking for a more built-in way to keep the system CPU distribution similar to what it would have been without pending - i.e. that each process is attributed with CPU time corresponding to what it has requested.
I’d appreciate any comment,
thank you.