multiple irp_mj_cleanup

hi all,
how to handle folowing scenario in irp_mj_cleanup.
(a) all the user handles to a file object are closed, hence irp_mj_cleanup
is dispatched to fsd.
(b) some kernel component re-creates a handle using ObOpenObjectByPointer,
using file object pointer.
(c) now this handle is now closed.

in step (c) since the user handle count for the file object once again
goes to 0, will io-manager, re dispatch irp_mj_cleanup to fsd? How is fsd
suppose to handle this situation? Does FO_CLEANUP_COMPLETE play some role
in this?

waiting for ur reply.

thanks
-kjo

This is a bug in the kernel component in (b). One should not bump the
HANDLE count once the handle has been closed. A file system would reject
this (since the handle is ALREADY cleaned up!)

Regards,

Tony

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

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: kjo [mailto:xxxxx@yahoo.com]
Sent: Wednesday, September 04, 2002 8:40 AM
To: File Systems Developers
Subject: [ntfsd] multiple irp_mj_cleanup

hi all,
how to handle folowing scenario in irp_mj_cleanup.
(a) all the user handles to a file object are closed, hence irp_mj_cleanup
is dispatched to fsd.
(b) some kernel component re-creates a handle using ObOpenObjectByPointer,
using file object pointer.
(c) now this handle is now closed.

in step (c) since the user handle count for the file object once again
goes to 0, will io-manager, re dispatch irp_mj_cleanup to fsd? How is fsd
suppose to handle this situation? Does FO_CLEANUP_COMPLETE play some role
in this?

waiting for ur reply.

thanks
-kjo


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

hi Tony,

i agree about it that it is a bug with kernel component and it should not
get handle from an object pointer which has already been cleaned up, but
how is it suppose to know whether that object has been cleanued up.

>> A file system would reject this (since the handle is ALREADY cleaned
up!)

Also where is the file system going to reject it, in the cleanup dispatch
?

thanks for ur earlier reply !
-Kjo

FO_CLEANUP_COMPLETE is set in FileObject->Flags. This is set by the FSD to
say “cleanup has already been performed on this file object.” What this
means is that data structures, etc. have been torn down - and the FSD won’t
be able to correctly tear things down a second time (I suppose one could
build an FSD to detect this and skip cleanup the second time around, but
that’s not the generally accepted model here.)

Regards,

Tony

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

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: kjo [mailto:xxxxx@yahoo.com]
Sent: Thursday, September 05, 2002 10:03 AM
To: File Systems Developers
Subject: [ntfsd] RE: multiple irp_mj_cleanup

hi Tony,

i agree about it that it is a bug with kernel component and it should not
get handle from an object pointer which has already been cleaned up, but
how is it suppose to know whether that object has been cleanued up.

>> A file system would reject this (since the handle is ALREADY cleaned
up!)

Also where is the file system going to reject it, in the cleanup dispatch
?

thanks for ur earlier reply !
-Kjo


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