Sara,
Sara Abraham wrote:
Thanks Tony, yes this all makes sense.
I think that there is another way that might be simpler than the ones
mentioned:
If the filter issues a ZwCreateFile() that it wants to later recognize, it
first issues an IoAllocateIrp() (dummy IRP which the filter will be able to
identify) followed by a IoEnqueueIrp() ( which will queue the IRP to the
current thread). ZwCreateFile() will allocate an IRP and will also queue it
to the thread’s list (at the head and still same thread). So no matter what
happens in between, other IRPs may be queued to the thread, but those two
will stay together. When the filter’s dispatch routine is invoked, if the
IRP is followed by the dummy IRP (Irp->ThreadListEntry), then it’s a
recursive call. This assumes that the IRP that the io manager created in
ZwCreateFile() is the one that the filter sees.
From my understanding of your idea you solve the recursion detection problem not
the deadlock problem induced by reentering the stack ?
The ‘shadow device’ solution is fine too. It has the side effect that
filters that attached to the original device, won’t see those
ZwCreateFile()-s. On the other hand, filters may notice the ‘shadow device’,
attach to them, and get confused.
In my implementation the shadow device is not attach to any other filter device
(it is almost a perfect duplicate of the original device object) It use a
private interface in the driver with the original DO and talk directly to what
it thinks is the bottom of the driver stack. They are some catches with this
approach though. (ex: closehandle() is dangerous in this case, for example as
you may re-enter the top of the stack because the iomanager will still use the
original vpb to find the top of the stack, if I recall).
Sara
-----Original Message-----
From: Tony Mason
> To: File Systems Developers
> Date: Thursday, July 13, 2000 8:04 AM
> Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand ler
>
>
…
>
Jerome.