Addref/Deref in shadow deviceIf I recall right, the Vpb spinlock is hold only for manipulation and checks on VPB. In Win 2k , Incrementeing the device reference count requires holding the IopDatabaseLock and not the Vpb lock. Doesnt make any sense
to hold the Vpb lock while working on a device object.
Dan
----- Original Message -----
From: Fuller, Rob
To: File Systems Developers
Sent: Wednesday, August 28, 2002 8:22 PM
Subject: [ntfsd] Re: Addref/Deref in shadow device
IIRC, the “IO Manager” grabs the VPB spinlock while decrementing the ReferenceCount as well as using InterlockedDecrement (Although this seems like overkill, there is a reason you might want to do something like this in multi-threaded programming, but I digress.) The VPB spinlock is exported by the functions IoAcquireVpbSpinLock and IoReleaseVpbSpinLock.
-----Original Message-----
From: Leonid Zhigunov [mailto:xxxxx@progate.spb.ru]
Sent: Wednesday, August 28, 2002 7:20 AM
To: File Systems Developers
Subject: [ntfsd] Re: Addref/Deref in shadow device
Well, seems the following code in
the shadow dispatch and complete works well…
ShadowDispatch ------------------------
IoCopyCurrentIrpStackLocationToNext(Irp);
IrpSp = IoGetNextIrpStackLocation(Irp);
IrpSp->DeviceObject = DeviceExtension->TargetDevice;
if (IrpSp->FileObject) {
IrpSp->FileObject->DeviceObject = DeviceExtension->RealDevice;
InterlockedIncrement(&DeviceExtension->RealDevice->ReferenceCount);
DerefOnFailure = TRUE;
}
IoSetCompletionRoutine(
Irp,
ShadowComplete,
(PVOID) DerefOnFailure,
TRUE, TRUE, TRUE
);
return(IoCallDriver(DeviceExtension->TargetDevice, Irp));
ShadowComplete:------------------------------
if (Irp->PendingReturned) {
IoMarkIrpPending(Irp);
}
if (NT_SUCCESS(Irp->IoStatus.Status)) {
//
// In the case of successfull open, we need to
// dereference our shadow device object, cause
// no one will do it on close.
//
InterlockedDecrement(&DeviceObject->ReferenceCount);
}
else {
//
// In the case of unsuccessfull open, we need
// to dereference real device object, if we
// have referenced it before.
//
if (DerefOnFailure) {
InterlockedDecrement(&DeviceExtension->RealDevice->ReferenceCount);
}
}
return(STATUS_SUCCESS);
Leonid.
P.S. I would also like to to have an example of rolling out
own create IRP. Could you send me it also. Thanks in advance.
“Vladimir Chtchetkine” wrote in message news:xxxxx@ntfsd…
I wander how to solve this puzzle…
When shadow device handles create IRP it must set FileObject->DeviceObject to
whatever is underlying volume (real) device. Otherwise NTFS will assert on volume
being not its volume. So, FileObject->DeviceObject must be replaced with underlying
volume device which means that on close IRP volume device’s refcount will be decremented
by I/O Mgr. So, it must be incremented in shadow’s create. And shadow device’s refcount
should be decremented (to maintain consistency). But decrementing shadow device’s refcount
causes another assertion (in I/O Mgr after IoCallDriver is completed) that expects this refcount
to be > 0. And even worst, because I/O Mgr assertion suggests that I/O Mgr uses a “cached” device
object instead of reusing the one that is addressed by FileObject->DeviceObject. So, if create
completes with a failure I/O Mgr will decrement “wrong” refcount (of shadow device) and will not
decrement volume’s refcount. So, looks like in shadow’s create dispatch I need to check create’s
status and rollback changes in case of failure. But (since create can be asynchronous) it’s not
that simple anymore 
So, is it really that puzzling, or am I just paying too much attention to these issues?
TIA,
Vladimir
—
You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%