I would like to point out that these issues with FAT deleting its device
object on close (and other operations) have been fixed in XP and later
so you should not have to worry about these issues in those
environments. Obviously if you have a filter running down level from
this you must sill worry about this.
Note that any environment that supports the filter manager has had these
issues fixed because the filter manager does not like accessing a freed
device object either
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Monday, November 08, 2004 2:38 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Question: IRP_MN_LOAD_FILE_SYSTEM in filter driver
Fortunately, file system load and unload is much better serialized
(within the I/O Manager) than the WDM bus driver case that you describe.
We gave up deleting everything in our fast I/O detach device entry point
years ago because of precisely the case you described - we used to see
FAT delete device objects in the IRP_MJ_CLOSE handler (after a dismount)
and if you deleted your filter’s device object in the detach routine it
would cause problems when that same device object was passed into your
completion routine. We resolved this by reference counting our device
objects. We’d bump the reference count for each IRP we passed to the
lower driver (with a completion routine) and decremented it in our
completion routine. We also used a reference for the attachment itself.
If you have an existing solution, it should resolve this issue as well.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Friday, November 05, 2004 11:41 AM
To: ntfsd redirect
Subject: RE: [ntfsd] Question: IRP_MN_LOAD_FILE_SYSTEM in filter driver
Thanks, Tony.
I believe deleting device object in dispatch routine will make the upper
driver extremely hard to code, and more likely, the upper will have no
choice but detach before sending the IRP down.
Let’s say:
- Driver A is above Driver B
- Driver A received a MN_LOAD_FILE_SYSTEM and sent it down without
detaching first.
- Driver B deletes its device object as the sample does.
- Driver A’s FastIoDetachDevice is invoked in the context of the
MN_LOAD_FILE_SYSTEM
- Driver A typically will de-allocate everything in its
FastIoDetachDevice routine. The problem is there are outstanding I/O
round,(at least the MN_LOAD_FILE_SYSTEM is still in progress). Driver
A’s FastIoDetachDevice routine can’t simply wait on outstanding I/O to
complete because the wait will certainly hang.
This race condition is very similar to the one in the WDM bus filter
driver. That’s – some bus driver deletes PDO upon IRP_MN_REMOVE_DEVICE
while the PDO was still reported in the most recent
QUERY_RELATION(busrelation). This will invoke bus filter’s
FastIoDetachDevice routine to delete the filter device object in the
context of its REMOVE_DEVICE path. In my WDM driver, I use a different
technique to solve the race condition and safely keep track of the
outstanding i/o though. Let’s me see if I can port it to my FS driver.
> Looking forward to seeing you at the Next OSR File Systems Class
April 4, 2004 in Boston!
Ah, that’s 8 hours drive from here. Let me check how much money left
after the coming tax season-
BTW, who will be the instructor?
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: November 4, 2004 4:08 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Question: IRP_MN_LOAD_FILE_SYSTEM in filter driver
Off the top of my head I can think of:
(1) The filter was written to work in a pre-callback timeframe. Since
the code works, nobody ever bothered to “fix it”
(2) The filter was written in the NT 4.0 timeframe and someone found the
quirky bug where you weren’t called to detach so the system just
crashed. Again, nobody ever bothered to change the code once the OS bug
was fixed…
There may be other reasons, but I suspect this is largely historical.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Thursday, November 04, 2004 2:27 PM
To: ntfsd redirect
Subject: [ntfsd] Question: IRP_MN_LOAD_FILE_SYSTEM in filter driver
I noticed that in some FS filter samples, the driver detaches itself
from the recognizer before sending the IRP down; re-attaches to the
recognizer if the FS is not loaded or deletes the filter object if the
FS is loaded.
My question is why detaching BEFORE passing IRP down? Is this to prevent
FAST_IO_DETACH_DEVICE being called on the filter object upon the
recognizer deleting its device object? Why not just keep it attached and
let FAST_IO_DETACH_DEVICE decide when to delete the filter object?
Thanks,
Calvin
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com