Hi,
I was wondering if anyone could provide some specifics about what guarantees with respect to concurrency are provided when unloading a minifilter driver.
More specifically, we have a driver that registers IRP_MJ_CREATE and IRP_MJ_NETWORK_QUERY_OPEN callbacks. It also has an unload callback in the FLT_REGISTRATION struct. Assume it has no other callbacks.
When the unload callback is called, is it possible that there are concurrently executing threads that have the IRP_MJ_XXX callbacks on their stacks?
If so, is it guaranteed that once FltUnregisterFilter returns, there are no longer any such outstanding stack frames?
Can new invocations of the IRP_MJ_XXX callbacks begin (in other threads) while the unload procedure is in the process of executing?
Can calling FltUnregisterFilter cause any synchronous calls (from the same thread) to the IRP_MJ_XXX callbacks given that we have no InstanceTeardown routine?
The reason I ask these things is because we use ExInitializeResourceLite to create a lock for our global state. I am wondering if I am at risk of
-
destroying the lock while other threads are waiting to acquire it (or already have it) or will try to acquire it in the future or
-
is it possible for threads executing IRP_MJ_XXX callbacks to use PFLT_FILTER value after FltUnregisterFilter has been called, and is that a problem?
> The reason I ask these things is because we use ExInitializeResourceLite to create a lock for global
state
Why having a global state instead of per-volume one?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>> The reason I ask these things is because we use ExInitializeResourceLite to create a lock for global
>state
Why having a global state instead of per-volume one?
It isn’t necessary for our purposes. We are totally agnostic about the volumes.
Let’s say for the sake of simplicity that our global state consists of a counter that counts operations and we want to guard it with a “ExInitializeResourceLite” lock.
Comments inline…
More specifically, we have a driver that registers IRP_MJ_CREATE and
IRP_MJ_NETWORK_QUERY_OPEN callbacks. It also has an unload callback in
the FLT_REGISTRATION struct. Assume it has no other callbacks.
When the unload callback is called, is it possible that there are
concurrently executing threads that have the IRP_MJ_XXX callbacks on
their stacks?
If I am correct, Yes.
If so, is it guaranteed that once FltUnregisterFilter returns, there
are no longer any such outstanding stack frames?
Yes.
Can new invocations of the IRP_MJ_XXX callbacks begin (in other
threads) while the unload procedure is in the process of executing?
No. But the post callbacks will come for which you have returned
FLT_PREOP_SUCCESS_WITH_CALLBACK in pre callback.
Can calling FltUnregisterFilter cause any synchronous calls (from the
same thread) to the IRP_MJ_XXX callbacks given that we have no
InstanceTeardown routine?
Yes. This can happen to drain the callback datas and to give you a chance to
cleanup any information associated with them. That is what the Flags
parameter of the post callback is used to detect.
The reason I ask these things is because we use
ExInitializeResourceLite to create a lock for our global state. I am
wondering if I am at risk of
-
destroying the lock while other threads are waiting to acquire it
(or already have it) or will try to acquire it in the future or
-
is it possible for threads executing IRP_MJ_XXX callbacks to use
PFLT_FILTER value after FltUnregisterFilter has been called, and is
that a problem?
Yes. It is possible. But the this PFLT_FILTER value is already valid until
the FltUnregisterFilter completes (or is just about to tear it down). But
make sure you don’t use it AFTER calling FltUnregisterFilter.
Regards,
Ayush Gupta
AI Consulting
>>
> If so, is it guaranteed that once FltUnregisterFilter returns, there
> are no longer any such outstanding stack frames?
>
Yes.
Ayush,
Thanks very much. That is exactly what I was hoping to hear.