Jamey,
If the request is synchronous, i’m afraid spawning a thread won’t solve
the recursion pb:
(I’m sorry if this this has been described several times)
If you have 2 filters A and B.
-Filter A open file1:
-(1) Filter A lock file1 with a private lock or whatever and so all new
requests to this file1 are made pending until this io is completed.
A give the request to B.
-Filter B needs for any reason to issue a synchronous ZwCreate for File
1 and spawn a thread whatever the context.
In the new thread:
-B Zwcreates() file1
-Filter B now reenter top of the driver stack by the io manager
(just doing its job) with the new thread.
=> The whole pb ‘shadow technique’ try to avoid <=
- and so the request reenter driver A and kick point (1) above and the
thread now waits for the original request to complete. If the original
request was made synchronous by filter B it will never come back to (1):
deadlock.
–
I didn’t had the kind of pbs Joel have.
You need messing with the irp/Fo when handling the special case to avoid
the ntclosehandle pb I mentioned in a previous post. (I also remember
now it triggered some pbs with the fastio table because NT thinks your
DO is now an FS).
Anyway that’s the kind of annoyance to account for when using this kind
of disgusting hacks, so I’m really interested if someone has another
generic solution to offer.
Jerome.
Jamey Kirby wrote:
Here is what I would do:- Create a system thread.- Post a request of
some sort to open the other file (via ZwCereateFile) to a queue that
the thread is waiting on.- When in the thread, open the file- If your
thread is reposnsible for the ZwCreateFile call to IRP_MJ_CREATE, then
you know it is your file. You can deterimine this by checking the
current thread on the create call or you can use the APIs in the ifs
kit to interogate the IRP for this information;
IoGetRequestorProcess(), etc…This has several advantages:- You
always know that your file creates will come from a know kernel-mode
thread.- If you do not need to serialize the second file open witht he
first, you can complete the original request- - If you do, you can
still block in the create handler until your thread processes the
create. Create is called at passive in the calling processes process
and thread context, so it is OK to let the scheduler switch to another
process and/or thread and do something at this point.Create calls are
slow and expensive anyhow, so another possible option, if you are
concerned about user context, is to create have a work queue manager
that can start and process stuff in system threads that are associated
with a know process; i.e. start the thread in the callers process,
post the request, ZwCreate the file, signal back to the create
dispatcher via an even that the ZwCreate stuff is complete and then
terminate the thread. I doubt the overhead of creatingh the thread
will impose any significant impact; especially if you do not need to
sync the create calls.Jamey-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith,
Joel
Sent: Monday, July 17, 2000 4:03 PM
To: File Systems Developers
Subject: [ntfsd] assertion while using ‘shadow device
object’ recursion removal te chnique
I’ve implemented my interpretation of the ‘shadow
device object’ technique that has been discussed over the
last couple days on this group. Basically, when creating my
filter device I create a second ‘shadow’ device with a
unique name. This shadow device is, of course, not in the
file system device stack.In my filter’s IRP_MJ_CREATE handler, if I have to
call ZwCreateFile, instead of initializing the file name
with the partition’s device object’s name prepended, I
prepend the name of my ‘shadow’ device: (i.e.
\Device\shadow_0\somefile.txt). I then call ZwCreateFile.Also in my filter’s IRP_MJ_CREATE handler is a
special case to handle creates redirected to the ‘shadow’
device object. (i.e.
ZwCreate(\Device\shadow_0\somefile.txt). If a create comes
in for the shadow device object the special case simply
forwards the create to the fsd with IoCallDriver.This technique works well 99% of the time.
Occasionally, however, I get an assertion from the FSD:*** Assertion failed: No correspondence btwn file and device
in irp((IrpSp->FileObject->Vpb == NULL) &&
((IrpSp->FileObject->DeviceObject != NULL) &&
(IrpSp->FileObject->DeviceObject->Vpb != NULL) &&
(IrpSp->DeviceObject == IrpSp->FileObject->DeviceObject->Vpb->DeviceObject))) || ((IrpSp->FileObject->Vpb !=
NULL) && (IrpSp->DeviceObject ==
IrpSp->FileObject->Vpb->DeviceObject)) || (!FlagOn(
Vcb->VcbState, VCB_STATE_VOLUME_MOUNTED ))*** Source File: D:\nt\private\ntos\cntfs\strucsup.c, line
6670This may not be enough to tell what I’ve done wrong,
but its all I’ve got now. I’ll update the thread with some
more information tommorrow, after I continue to debug the
problem (I’m just hoping the problem will be obvious to one
of you and you can save me time :))Thanks,
Joel