OSR's article, IRP_MJ_CLOSE and CcGetFileObjectFromSectionPtrs()

Slava_Imameyev · June 11, 2006, 1:12pm

The OSR’s article http://www.osronline.com/article.cfm?id=102 suggests the
following algorithm

"For a filter driver that is only concerned about data operations (read and
write) this suggests a simpler algorithm:

For each IRP_MJ_CREATE, the filter driver increments the reference count
on the per-file context structure.
For each IRP_MJ_CLOSE the filter driver decrements the reference count on
the per-file context structure if the FO_STREAM_FILE bit is not set for the
file object and if CcGetFileObjectFromSectionPtrs does not return this file
object.
If the reference count for the per-file context structure reaches zero and
both the ImageSectionObject and DataSectionObject of the
SectionObjectPointers field from the FILE_OBJECT is zero, the filter driver
may then delete the per-file context data.
"

My question concerns the use of CcGetFileObjectFromSectionPtrs to get a
file object while processing the IRP_MJ_CLOSE. The article suggests to get
the file object which is used to back the shared cache map( i.e. to call
CcGetFileObjectFromSectionPtrs ), but this file object is referenced by the
system when creating the shared cache map in CcInitializeCacheMap() and must
be dereferenced only before changing the pointer or deleting the shared
cache map. It seems meaningless to get this pointer in IRP_MJ_CLOSE ,
because

If the shared cache map has been deleted the
SectionObjectPointer->SharedCacheMap is NULL, and it must be set to NULL
before dereferencing the file object therefore the file object returned by
CcGetFileObjectFromSectionPtrs is also NULL.
If the shared cache map is valid the file object which backs it is
referenced( i.e. IRP_MJ_CLOSE can’t be sent ).

OSR_Community_User · June 11, 2006, 1:29pm

Your conclusions are almost correct, 2) is not quite right. The IRP_MJ_CLOSE
will be issued against some fileobject whose pointer count is zero. The call
into Ccxxx is to see if there is still an outstanding count in the CC
subsystem. If it returns NULL then you know there is not otherwise there is.

You are confusing the issuing of the IRP_MJ_CLOSE with which FO it is issued
against. You are correct, it won’t be issued against the FO that CC has the
reference on, the one returned from the Ccxxx call, but it will be issued
against one of the open fileobjects of the file that you have per file
context data allocated against.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-253764-
xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Sunday, June 11, 2006 11:29 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] OSR’s article, IRP_MJ_CLOSE and
CcGetFileObjectFromSectionPtrs()

The OSR’s article http://www.osronline.com/article.cfm?id=102 suggests
the
following algorithm

"For a filter driver that is only concerned about data operations (read
and
write) this suggests a simpler algorithm:

For each IRP_MJ_CREATE, the filter driver increments the reference count
on the per-file context structure.
For each IRP_MJ_CLOSE the filter driver decrements the reference count
on
the per-file context structure if the FO_STREAM_FILE bit is not set for
the
file object and if CcGetFileObjectFromSectionPtrs does not return this
file
object.
If the reference count for the per-file context structure reaches zero
and
both the ImageSectionObject and DataSectionObject of the
SectionObjectPointers field from the FILE_OBJECT is zero, the filter
driver
may then delete the per-file context data.
"

My question concerns the use of CcGetFileObjectFromSectionPtrs to get a
file object while processing the IRP_MJ_CLOSE. The article suggests to get
the file object which is used to back the shared cache map( i.e. to call
CcGetFileObjectFromSectionPtrs ), but this file object is referenced by
the
system when creating the shared cache map in CcInitializeCacheMap() and
must
be dereferenced only before changing the pointer or deleting the shared
cache map. It seems meaningless to get this pointer in IRP_MJ_CLOSE ,
because

If the shared cache map has been deleted the
SectionObjectPointer->SharedCacheMap is NULL, and it must be set to NULL
before dereferencing the file object therefore the file object returned by
CcGetFileObjectFromSectionPtrs is also NULL.

If the shared cache map is valid the file object which backs it is
referenced( i.e. IRP_MJ_CLOSE can’t be sent ).

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

OSR_Community_User · June 11, 2006, 3:10pm

I am confused now,

You are confusing the issuing of the IRP_MJ_CLOSE
with which FO it is issued
against. You are correct, it won’t be issued against
the FO that CC has the
reference on, the one returned from the Ccxxx call,
but it will be issued
against one of the open fileobjects of the file that
you have per file
context data allocated against.

For eg. lets say I get a create request on the
file\foo.txt with FO: 0xXYZ, I allocate per file
context for this FO.

I get IRP_MJ_CLOSE on the FO:0xXYZ,

FO_STREAM_FILE is not set on the FO and
CcGetFileObjectFromSectionPtrs(0xXYZ->SectionObjectPointers)
return me 0xXXZ

now since 0xXXZ != 0xXYZ does that mean we can delete
the perfile context for the 0xXYZ?

isn’t 0xXXZ returned by CcXxx call indicates that
0xXXZ is a CC reference on the file repsresented by
the 0xXYZ?

Please explain.

Thanks & Regards,
Rohit

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Slava_Imameyev · June 11, 2006, 3:23pm

I think you can’t remove per-file context, because the stream for the file
is in use.
I think you must delete the per-file context then the third condition will
be true( i.e. “If the reference count for the per-file context structure
reaches zero and
both the ImageSectionObject and DataSectionObject of the
SectionObjectPointers field from the FILE_OBJECT is zero” ) and
CcGetFileObjectFromSectionPtrs returns NULL.

“Rohit Kumar” wrote in message news:xxxxx@ntfsd…
>I am confused now,
>
>> You are confusing the issuing of the IRP_MJ_CLOSE
>> with which FO it is issued
>> against. You are correct, it won’t be issued against
>> the FO that CC has the
>> reference on, the one returned from the Ccxxx call,
>> but it will be issued
>> against one of the open fileobjects of the file that
>> you have per file
>> context data allocated against.
>
> For eg. lets say I get a create request on the
> file\foo.txt with FO: 0xXYZ, I allocate per file
> context for this FO.
>
> I get IRP_MJ_CLOSE on the FO:0xXYZ,
>
> FO_STREAM_FILE is not set on the FO and
> CcGetFileObjectFromSectionPtrs(0xXYZ->SectionObjectPointers)
> return me 0xXXZ
>
> now since 0xXXZ != 0xXYZ does that mean we can delete
> the perfile context for the 0xXYZ?
>
> isn’t 0xXXZ returned by CcXxx call indicates that
> 0xXXZ is a CC reference on the file repsresented by
> the 0xXYZ?
>
> Please explain.
>
> Thanks & Regards,
> Rohit
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

OSR_Community_User · June 11, 2006, 4:47pm

Thanks for the reply All.

Regards,
Rohit

— Slava Imameyev wrote:

> I think you can’t remove per-file context, because
> the stream for the file
> is in use.
> I think you must delete the per-file context then
> the third condition will
> be true( i.e. “If the reference count for the
> per-file context structure
> reaches zero and
> both the ImageSectionObject and DataSectionObject of
> the
> SectionObjectPointers field from the FILE_OBJECT is
> zero” ) and
> CcGetFileObjectFromSectionPtrs returns NULL.
>
>
>
> “Rohit Kumar” wrote in
> message news:xxxxx@ntfsd…
> >I am confused now,
> >
> >> You are confusing the issuing of the IRP_MJ_CLOSE
> >> with which FO it is issued
> >> against. You are correct, it won’t be issued
> against
> >> the FO that CC has the
> >> reference on, the one returned from the Ccxxx
> call,
> >> but it will be issued
> >> against one of the open fileobjects of the file
> that
> >> you have per file
> >> context data allocated against.
> >
> > For eg. lets say I get a create request on the
> > file\foo.txt with FO: 0xXYZ, I allocate per file
> > context for this FO.
> >
> > I get IRP_MJ_CLOSE on the FO:0xXYZ,
> >
> > FO_STREAM_FILE is not set on the FO and
> >
>
CcGetFileObjectFromSectionPtrs(0xXYZ->SectionObjectPointers)
> > return me 0xXXZ
> >
> > now since 0xXXZ != 0xXYZ does that mean we can
> delete
> > the perfile context for the 0xXYZ?
> >
> > isn’t 0xXXZ returned by CcXxx call indicates that
> > 0xXXZ is a CC reference on the file repsresented
> by
> > the 0xXYZ?
> >
> > Please explain.
> >
> > Thanks & Regards,
> > Rohit
> >
> >
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com