Filter Manager - FltGetStreamContext returning "stale" data

NTFSD
1

I’m not at all sure where the following problem exists - however, it appears
as if the Filter Manager function FltGetStreamContext() returns context data
that allegedly has been “freed”. I think it to be freed because my Context
Cleanup Callback has been invoked.

A quick outline of what is happening: In my PostCreate routine I call
FltGetStreamContext() to see if I am already tracking the stream. If it
fails, I allocate a new context and call FltSetStreamContext. If I get a
returned context, I increment its refcount (FltReferenceContext). In my
PostClose processing, I call FltReleaseContext(streamContext) for every
FileObject I am tracking (I am also creating StreamHandle Contexts for each
FileObject I am tracking). When my refcount on the stream goes to zero, I
see my ContextCleanupCallback invoked as expected. On the next PostCreate
call (same directory), FltGetStreamContext returns me the context I have
just reset! From the looks of it, the Filter Manager ref count is now 1 -
this should not be!

At first I saw crashes in FltGetStreamContext and I thought it was just a
simple race between CREATE and CLOSE processing of the contexts, so I added
some serialization around the FltGetStreamContext/context creation in CREATE
and the FltReleaseContext calls in CLOSE. This did stop the crashes in the
FltGetStreamContext. The only problem is the return of the “stale” context
that my driver believes has been freed!!!

Is this a known problem/deficiency in the Filter Manager or am I totally
incorrect in my attempt to track open contexts?

Need more info?

/ted

2

Ted,

The filter manager does not return stale contexts which have been freed.
I believe this is occurring because you are doing your own ref counting.

Do not do your own ref counting, there is no need. The filter manager
will do this for you. It properly manages context lifetime.

In post-create it is reasonable to call GetStreamContext to see if one
already exists. If not, create your own and call set with
"keepIfExists" and specify and "old" value so you can get the one that
got set. If you get back an old value, do not ref it, just release it
when you are done. Note that you do need to release the context that
failed to be set so it will be freed.

Then whenever you get the context simply release it when you are done.
When the stream actually goes away the context will be properly deleted
from the system and your cleanup routine will be called.

Please try this and see if it doesn't work fine for you.

If you still have an issue I will need you to send me a test filter that
demonstrates your problem along with the source and I will take a look.

Neal

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Tuesday, March 02, 2004 10:07 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter Manager - FltGetStreamContext returning "stale"
data

I'm not at all sure where the following problem exists - however, it
appears
as if the Filter Manager function FltGetStreamContext() returns context
data
that allegedly has been "freed". I think it to be freed because my
Context
Cleanup Callback has been invoked.

A quick outline of what is happening: In my PostCreate routine I call
FltGetStreamContext() to see if I am already tracking the stream. If it
fails, I allocate a new context and call FltSetStreamContext. If I get a
returned context, I increment its refcount (FltReferenceContext). In my
PostClose processing, I call FltReleaseContext(streamContext) for every
FileObject I am tracking (I am also creating StreamHandle Contexts for
each
FileObject I am tracking). When my refcount on the stream goes to zero,
I
see my ContextCleanupCallback invoked as expected. On the next
PostCreate
call (same directory), FltGetStreamContext returns me the context I have
just reset! From the looks of it, the Filter Manager ref count is now 1

this should not be!

At first I saw crashes in FltGetStreamContext and I thought it was just
a
simple race between CREATE and CLOSE processing of the contexts, so I
added
some serialization around the FltGetStreamContext/context creation in
CREATE
and the FltReleaseContext calls in CLOSE. This did stop the crashes in
the
FltGetStreamContext. The only problem is the return of the "stale"
context
that my driver believes has been freed!!!

Is this a known problem/deficiency in the Filter Manager or am I totally
incorrect in my attempt to track open contexts?

Need more info?

/ted

Questions? First check the IFS FAQ at

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com