In our file system, we need to be able to track when files have been mapped and unmapped (so that we can take other actions around the file that it being mapped would prohibit). Our working assumption has been that a file will only transition from being unmapped to mapped between calls to the AcquireFileForNtCreateSection() and ReleaseFileForNtCreateSection() methods of the FAST_IO_DISPATCH table that is being exported by the filesystem driver object (this is not explictily stated in Rageev’s book, but it is strongly implied).
We’ve recently started seeing failed ASSERTs (on entry to the file system) because the file is now mapped but the last time the file transitioned between the Acquire and Release methods the file was not mapped (in other words, the file seems to have become mapped without our FS being involved in the process). We first started seeing this happen in testing with ForeFront, but have very recently seen this happen without ForeFront (or any other filter) involved.
Our assumption in the FS has always been that all system components would honor the callbacks to the Acquire/Release entry points, because without doing that the locking hierarchy for the FS is broken (this is my interpretation, and it may not be the right one).
So, one of two things is happening:
1.) Our assumption that Windows only changes a file to being mapped between the
Acquire and Release methods is wrong.
or
2.) The ForeFront Client Security AV realtime scanning filter (or some other component) maps the file without calling the Acquire/Release methods. Note that we don’t see this with other AV filters.
So, my question(s) for the assembled minds here:
-
Have you seen instances where file mapping does not go through the locking FASTIO calls, as we believed that it must?
-
Are our assumptions here correct in the first place?
We’re at a loss here, it looks very much as if our assumptions are wrong (or we have some very subtle bug in our FS, which we’ve been looking for without success.)
(FWIW, this is on Win2k3R2 only)
Thanks…dave
Hi,
wrote in message news:xxxxx@ntfsd…
> In our file system, we need to be able to track when files have been
mapped and unmapped (so that we can take other actions around the file that
it being mapped would prohibit). Our working assumption has been that a
file will only transition from being unmapped to mapped between calls to the
AcquireFileForNtCreateSection() and ReleaseFileForNtCreateSection() methods
of the FAST_IO_DISPATCH table that is being exported by the filesystem
driver object (this is not explictily stated in Rageev’s book, but it is
strongly implied).
>
> We’ve recently started seeing failed ASSERTs (on entry to the file system)
because the file is now mapped but the last time the file transitioned
between the Acquire and Release methods the file was not mapped (in other
words, the file seems to have become mapped without our FS being involved in
the process). We first started seeing this happen in testing with ForeFront,
but have very recently seen this happen without ForeFront (or any other
filter) involved.
>
> Our assumption in the FS has always been that all system components would
honor the callbacks to the Acquire/Release entry points, because without
doing that the locking hierarchy for the FS is broken (this is my
interpretation, and it may not be the right one).
>
> So, one of two things is happening:
>
> 1.) Our assumption that Windows only changes a file to being mapped
between the
> Acquire and Release methods is wrong.
> or
> 2.) The ForeFront Client Security AV realtime scanning filter (or some
other component) maps the file without calling the Acquire/Release methods.
Note that we don’t see this with other AV filters.
>
> So, my question(s) for the assembled minds here:
>
> 1) Have you seen instances where file mapping does not go through the
locking FASTIO calls, as we believed that it must?
Yes, some filters may not propagate the fastio call down due to bugs. In
some cases the call fails but an irp is sent and mask the bug.
>
> 2) Are our assumptions here correct in the first place?
Did you try to double check your lock hierarchy by implementing
FS_FILTER_CALLBACKS calls/traces ? it gives higher control to the file.
>
> We’re at a loss here, it looks very much as if our assumptions are wrong
(or we have some very subtle bug in our FS, which we’ve been looking for
without success.)
>
> (FWIW, this is on Win2k3R2 only)
>
> Thanks…dave
>
Jerome.
If I understand you correctly, you’re suggesting that we build a filter over the filesystem that catches the sync request on it’s way in or out of the FS (these would be things like PreAcquireForCCFlush and compatriots) and use that as a tracking mechanism for calls into the mapping activity? This sounds like it could be a useful debugging tool - and we do have a filter already in place that we could do this in. Hmmm…
thanks…dave
Hi,
Yes, try to match these callbacks with your acquire() routines.
They are entries for the acquire sections too if I recall.
I’m not sure if this FS_FILTER_CALLBACKS api bothers to check if it is
called from a filter ?
wrote in message news:xxxxx@ntfsd…
> If I understand you correctly, you’re suggesting that we build a filter
over the filesystem that catches the sync request on it’s way in or out of
the FS (these would be things like PreAcquireForCCFlush and compatriots) and
use that as a tracking mechanism for calls into the mapping activity? This
sounds like it could be a useful debugging tool - and we do have a filter
already in place that we could do this in. Hmmm…
>
> thanks…dave
>
Jerome.