IoGetTopLevelIrp and file sys call rule

NTFSD
1

one of the rules says : Don’t issue file system calls if IoGetTopLevelIrp()
returns a non-NULL value
is the rule also valid for a FltIsDirectory call from the minifilter.

Mani

2

Ah, so many misconceptions in a short post.

First, I wouldn’t even agree with that rule. Maybe it should be prefaced with “if you do not understand re-entrancy and lock management…”

Why are you asking this in a context in which this value is set in the first place? In general, this is something I’d expect you to ask during post-create and then save that information away; you shouldn’t be seeing this set in contexts in which you are asking for this information.

In the specific case, I’d generally be inclined to trust that the filter manager team has done their job right and if you call it at a point when you shouldn’t, they’ll definitely tell you so. The documentation doesn’t list any restrictions of this type, either. Have you actually tried calling it?

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

3

Tony

i am making a call from PostWrite and the thread making the call hangs
forever. see the call stk below.
now i check if IoGetTopLevelIrp is returning NULL. only if it retunrs NULL i
call FltIsDirectory. that solves the hang.

tell me if i am wrong or is there a bug in FltIsDirectory. infact there is
one more such post in ntfsd which says the same.

nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
nt!KiSwapThread+0x46 (FPO: [0,0,0])
nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
Ntfs!NtfsWaitForIoAtEof+0x49 (FPO: [Non-Fpo])
Ntfs!NtfsCommonQueryInformation+0x117 (FPO: [Non-Fpo])
Ntfs!NtfsFsdDispatchSwitch+0x12a (FPO: [Non-Fpo])
Ntfs!NtfsFsdDispatchWait+0x1c (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
sr!SrPassThrough+0x31 (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
fltMgr!FltpQueryInformationFile+0x99 (FPO: [Non-Fpo])
fltMgr!SetStreamListStandardInformationFlags+0x7e (FPO: [Non-Fpo])
fltMgr!FltIsDirectory+0x40 (FPO: [Non-Fpo])
fsfmydriver!MoreProc+0x9f (FPO: [Non-Fpo])
fsfmydriver!CheckCache+0x4d (FPO: [Non-Fpo])
fsfmydriver!PostWrite+0x22 (FPO: [Non-Fpo]) (CONV: stdcall)
fltMgr!FltvPostOperation+0x4d (FPO: [Non-Fpo])
fltMgr!FltpPerformPostCallbacks+0x1c5 (FPO: [Non-Fpo])
fltMgr!FltpProcessIoCompletion+0x10 (FPO: [Non-Fpo])
fltMgr!FltpPassThroughCompletion+0x89 (FPO: [Non-Fpo])
nt!IovpLocalCompletionRoutine+0xb4 (FPO: [Non-Fpo])
nt!IopfCompleteRequest+0xa2 (FPO: [Non-Fpo])
nt!IovCompleteRequest+0x9a (FPO: [Non-Fpo])
Ntfs!NtfsCompleteRequest+0xac (FPO: [Non-Fpo])
Ntfs!NtfsCommonWrite+0x2095 (FPO: [Non-Fpo])
Ntfs!NtfsFsdWrite+0xf3 (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
sr!SrWrite+0xaa (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b (FPO: [Non-Fpo])
fltMgr!FltpDispatch+0x104 (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
nt!IoSynchronousPageWrite+0xaf (FPO: [Non-Fpo])
nt!MiFlushSectionInternal+0x38b (FPO: [Non-Fpo])
nt!MmFlushSection+0x1e0 (FPO: [Non-Fpo])

!!!

wrote in message news:xxxxx@ntfsd…
> Ah, so many misconceptions in a short post.
>
> First, I wouldn’t even agree with that rule. Maybe it should be prefaced
> with “if you do not understand re-entrancy and lock management…”
>
> Why are you asking this in a context in which this value is set in the
> first place? In general, this is something I’d expect you to ask during
> post-create and then save that information away; you shouldn’t be seeing
> this set in contexts in which you are asking for this information.
>
> In the specific case, I’d generally be inclined to trust that the filter
> manager team has done their job right and if you call it at a point when
> you shouldn’t, they’ll definitely tell you so. The documentation doesn’t
> list any restrictions of this type, either. Have you actually tried
> calling it?
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>

4

it is reproducible.

Tony

i am making a call from PostWrite and the thread making the call hangs
forever. see the call stk below.
now i check if IoGetTopLevelIrp is returning NULL. only if it retunrs NULL
i
call FltIsDirectory. that solves the hang.

tell me if i am wrong or is there a bug in FltIsDirectory. infact there is
one more such post in ntfsd which says the same.

nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
nt!KiSwapThread+0x46 (FPO: [0,0,0])
nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
Ntfs!NtfsWaitForIoAtEof+0x49 (FPO: [Non-Fpo])
Ntfs!NtfsCommonQueryInformation+0x117 (FPO: [Non-Fpo])
Ntfs!NtfsFsdDispatchSwitch+0x12a (FPO: [Non-Fpo])
Ntfs!NtfsFsdDispatchWait+0x1c (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
sr!SrPassThrough+0x31 (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
fltMgr!FltpQueryInformationFile+0x99 (FPO: [Non-Fpo])
fltMgr!SetStreamListStandardInformationFlags+0x7e (FPO: [Non-Fpo])
fltMgr!FltIsDirectory+0x40 (FPO: [Non-Fpo])
fsfmydriver!MoreProc+0x9f (FPO: [Non-Fpo])
fsfmydriver!CheckCache+0x4d (FPO: [Non-Fpo])
fsfmydriver!PostWrite+0x22 (FPO: [Non-Fpo]) (CONV: stdcall)
fltMgr!FltvPostOperation+0x4d (FPO: [Non-Fpo])
fltMgr!FltpPerformPostCallbacks+0x1c5 (FPO: [Non-Fpo])
fltMgr!FltpProcessIoCompletion+0x10 (FPO: [Non-Fpo])
fltMgr!FltpPassThroughCompletion+0x89 (FPO: [Non-Fpo])
nt!IovpLocalCompletionRoutine+0xb4 (FPO: [Non-Fpo])
nt!IopfCompleteRequest+0xa2 (FPO: [Non-Fpo])
nt!IovCompleteRequest+0x9a (FPO: [Non-Fpo])
Ntfs!NtfsCompleteRequest+0xac (FPO: [Non-Fpo])
Ntfs!NtfsCommonWrite+0x2095 (FPO: [Non-Fpo])
Ntfs!NtfsFsdWrite+0xf3 (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
sr!SrWrite+0xaa (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b (FPO:
[Non-Fpo])
fltMgr!FltpDispatch+0x104 (FPO: [Non-Fpo])
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
nt!IoSynchronousPageWrite+0xaf (FPO: [Non-Fpo])
nt!MiFlushSectionInternal+0x38b (FPO: [Non-Fpo])
nt!MmFlushSection+0x1e0 (FPO: [Non-Fpo])

!!!

wrote in message news:xxxxx@ntfsd…
> Ah, so many misconceptions in a short post.
>
> First, I wouldn’t even agree with that rule. Maybe it should be prefaced
> with “if you do not understand re-entrancy and lock management…”
>
> Why are you asking this in a context in which this value is set in the
> first place? In general, this is something I’d expect you to ask during
> post-create and then save that information away; you shouldn’t be seeing
> this set in contexts in which you are asking for this information.
>
> In the specific case, I’d generally be inclined to trust that the filter
> manager team has done their job right and if you call it at a point when
> you shouldn’t, they’ll definitely tell you so. The documentation doesn’t
> list any restrictions of this type, either. Have you actually tried
> calling it?
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>