Hello everybody,
I have a FS minifilter driver in which i need to detect whether a call is a recursive call issued from a filter driver below me using ZwXXXFile apis that send the I/O to the top of the stack.
What are the various ways in which this can be detected?
Thank you,
Tushar
> I have a FS minifilter driver in which i need to detect whether a call is
a recursive
call issued from a filter driver below me using ZwXXXFile apis that send
the I/O
to the top of the stack.What are the various ways in which this can be detected?
To answer *exactly* your question: You will be called within the context of
the same thread so it suffices to squirrel away a list of active threads
when you call down and to check against that list when you are called.
However what you describe is not where most re-entrancy happens and
certainly not the hardest. Further, it is not unreasonable to assume that
filters below you that issue ZwXXX will be removing those calls in response
to the pain that they cause.
Many lower filters cause re-entrancy in a different thread and often a
different process.
In general your filter *has* to be able to handle such re-entrant calls from
drivers below you up to and including the FSD (sometimes even in the device
stack below the FSD). If you are pre-ship now is a really good time to fix
that.
If you have product shipping there are some tricks you can pull to reduce
this to the level of “major pain” while you spend the time fixing your
filter. For instance “SR only re-enters on the first write to a new volume
it hasn’t seen before” and “FileInfo only re-enters in response to requests
(direct or indirect) from CcPf”. But you will have continuous pain until
you get your filter fixed.
Good luck.
Rod
Steading System Software
Thank you for your reply…
I need to handle recursion in Create Callback. In my post create callback, i open another handleto the file. So, i need to know whether this is a recursive call, otherwise i will initiate one more create request using FltCreateFile and then some filter below me might issue ZwCreateFile again for its work… And this will continue until system crashes…
Whats is the good way to handle this.
Thank you,
Tushar
Assuming that this is in successful post-create why not:
This of course is assuming that you only need one extra create per create.
Rod
wrote in message news:xxxxx@ntfsd…
> Thank you for your reply…
> I need to handle recursion in Create Callback. In my post create callback,
> i open another handleto the file. So, i need to know whether this is a
> recursive call, otherwise i will initiate one more create request using
> FltCreateFile and then some filter below me might issue ZwCreateFile again
> for its work… And this will continue until system crashes…
> Whats is the good way to handle this.
>
> Thank you,
> Tushar
>
Rod,
Wouldn’t that be stream handle context? If he stores that information
in stream context, he might get confused with another thread creating
another handle for the same file?
What I do to mitigate problems similar to this was closer to your first
suggestion. I rolled a simple thread context to help keep track of what
is going on. Obviously that doesn’t help if someone shifts the I/O to a
worker thread.
One of my very few frustrations with the
filter manager is that it doesn’t implement thread and process context
to go along with the rich set of contexts it does provide. At one time
Neal (maybe Sarosh?) said this was on the list of things to do, but it
never happened. Yes, these contexts are not related to the file
system. However, they would help complete an otherwise wonderful
context set.
Rod Widdowson wrote:
> Assuming that this is in successful post-create why not:
>
> 1) Check for a stream context
> 2) If there is no stream context add one with a state variable in it
> saying “handing post create create”, then do the second create
> 3) If there is a stream context check the state variable and do
> “Whatever is appropriate”.
>
> This of course is assuming that you only need one extra create per
> create.
>
> Rod
>
>
> wrote in message news:xxxxx@ntfsd…
>> Thank you for your reply…
>> I need to handle recursion in Create Callback. In my post create
>> callback, i open another handleto the file. So, i need to know
>> whether this is a recursive call, otherwise i will initiate one more
>> create request using FltCreateFile and then some filter below me
>> might issue ZwCreateFile again for its work… And this will continue
>> until system crashes…
>> Whats is the good way to handle this.
>>
>> Thank you,
>> Tushar
>>
>
>
> —
> 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
>
> Wouldn’t that be stream handle context? If he stores that information in
stream context, he might get confused with another thread creating another
handle for the same file?
I thought about that but there are two options:
He only needs a spare file objectto do something ona per stream basis.
This seemed more likely to me so I answered that.
He *really* does need a new file object for every file object, in that
case he needs one for non-thread-reentrant (but reentrant nontheless)
creates as well (they are coming from the top of the stack for a reason).
In that case he should be creating the second file object.
Anyway, using a SHC won’t help (different File object, different SHC). If
he *really* does need a new file object he has some very special constraints
and would be better coding them up. For myself I can only imaging needing
perhaps absolutely max 3 (one with write privs, one with read and one with
delete).
I’d agree that thread context are extra-ordinarily useful things (after all,
thats what FSD’s use TopLevelIrp for). Actually an IRP context would be
useful as well.
R