Is it possible that two different IRP executing in diffrent threads whose
fileobjects are pointing to diffrent volumes could try to aquire the same
VCB. I thought VCB is related to volume but i observed a deadlock in which
two threads processing IRPs for diffrent volumes and one has already
acquired an resource exclusively and other is trying to acquire the same VCB
already acruired by first thread using NtfsAcquireSharedVcb. Is it possible
or i am doing some mistake
The Documentation in DDK says that
VCB
Volume control block. An internal file system structure in which a file
system maintains state about a mounted volume.
So I thought VCB should be diffrent for diffrent volume. But i have seen a
deadlock in which IRPs for diffrent volume tries tro acquire the same VCB.
The deadlock is
thread 85e882d8 IRP 8757cf20 whose fileobject points to volume
{VVolume0{05d460a6-0a78-11dc-90b}(volume created by me)
ChildEBP RetAddr Args to Child
85e88378 85e882d8 f66b53b4 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
8757cf20 f66b5530 e126a558 nt!KiSwapThread+0x280 (FPO: [Non-Fpo])
f66b53b4 00000000 00000000 nt!KeWaitForSingleObject+0x249 (FPO: [Non-Fpo])
f66b5530 00000000 f66b5530 Ntfs!NtfsWaitSync+0x18 (FPO: [1,0,0])
f66b5530 8757cf20 e126a558 Ntfs!NtfsNonCachedIo+0x2f3 (FPO: [Non-Fpo])
f66b5530 8757cf20 0108070a Ntfs!NtfsCommonWrite+0x18a0 (FPO: [Non-Fpo])
85a82718 8757cf20 8757cfd8 Ntfs!NtfsFsdWrite+0x16a (FPO: [Non-Fpo])
f5fe7bbe f5fe7bbe 8757cf20 nt!IovCallDriver+0x110 (FPO: [Non-Fpo])
8757cf20 85e2f888 862ad5d8 nt!IofCallDriver+0xe (FPO: [0,0,0])
WARNING: Stack unwind information not available. Following frames may be
wrong.
8757cf20 f66b5748 80747a30 naiavf5x+0x1bbe
8757cf20 80747a30 85ac5648 naiavf5x+0x72ce
85ac5648 8757cf20 862ad5d8 naiavf5x+0x2520
804f8caa 804f8caa f66b57c8 nt!IovCallDriver+0x110 (FPO: [Non-Fpo])
f66b57c8 f66b5968 85ddc770 nt!IofCallDriver+0xe (FPO: [0,0,0])
862ad503 f66b57c8 f66b5844 nt!IoSynchronousPageWrite+0xad (FPO: [Non-Fpo])
e10aa700 e10aa740 e10aa740 nt!MiFlushSectionInternal+0x3c4 (FPO: [Non-Fpo])
85ddc770 00000000 00010000 nt!MmFlushSection+0x22d (FPO: [Non-Fpo])
00010000 00000000 00000000 nt!CcFlushCache+0x37d (FPO: [Non-Fpo])
867bf468 e126a558 00000000 Ntfs!NtfsFlushUserStream+0x6a (FPO: [Non-Fpo])
867bf468 85a827f8 00000001 Ntfs!NtfsFlushVolume+0x221 (FPO: [Non-Fpo])
867bf468 86ef0f20 86337eb8 Ntfs!NtfsVolumeDasdIo+0xbf (FPO: [Non-Fpo])
867bf468 86ef0f20 00000001 Ntfs!NtfsCommonRead+0x1d5 (FPO: [Non-Fpo])
85a82718 86ef0f20 86ef0f20 Ntfs!NtfsFsdRead+0x20f (FPO: [Non-Fpo])
f5fed4a0 f5fed4a0 80747a30 nt!IovCallDriver+0x110 (FPO: [Non-Fpo])
80747a30 85e4e270 00000000 nt!IofCallDriver+0xe (FPO: [0,0,0])
86ef0f20 80747a30 85ac5648 naiavf5x+0x74a0
85ac5648 86ef0f20 86ef0f20 naiavf5x+0x2520
80585208 80585208 86ef0fd8 nt!IovCallDriver+0x110 (FPO: [Non-Fpo])
86ef0fd8 86ef0f20 858ff750 nt!IofCallDriver+0xe (FPO: [0,0,0])
85ac5648 86ef0f20 858ff750 nt!IopSynchronousServiceTail+0x6f (FPO:
[Non-Fpo])
00000254 00000000 00000000 nt!NtReadFile+0x566 (FPO: [Non-Fpo])
00000254 00000000 00000000 nt!KiSystemService+0xd0 (FPO: [0,0] TrapFrame @
f66b5d64)
00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4 (FPO: [0,0,0])
0: kd> !irp 8757cf20
Irp is active with 3 stacks 1 is current (= 0x8757cf90)
Mdl=f66b57c8: No System Buffer: Thread 85e882d8: Irp stack trace.
cmd flg cl Device File Completion-Context
[4, 0] 0 e1 85ac5aa8 00000000 bade2ca0-f66b53a8 Success Error Cancel
pending
\Driver\MyDrv Ntfs!NtfsSingleSyncCompletionRoutine
Args: 00010000 00000000 1bde6200 00000000
[4, 0] 0 e0 85a82718 862ad5d8 f5fe7b50-f66b56e8 Success Error Cancel
\FileSystem\Ntfs naiavf5x
Args: 00010000 00000000 001c0000 00000000
[4, 0] 0 0 85ac5648 862ad5d8 00000000-00000000
\FileSystem\NaiAvFilter1
Args: 00010000 00000000 001c0000 00000000
0: kd> !object 862ad5d8
Object: 862ad5d8 Type: (868f24b0) File
ObjectHeader: 862ad5c0
HandleCount: 0 PointerCount: 2
Directory Object: 00000000 Name: \300\C00000357.DAT
{VVolume0{05d460a6-0a78-11dc-90b}
thread 85e63ae8 IRP 87014e48 whose fileobject points to volume
HarddiskVolume2
0: kd> kb 50
ChildEBP RetAddr Args to Child
85e63b88 85e63ae8 85b58e88 nt!KiSwapContext+0x26
85e63ae8 85a82c2c 00000000 nt!KiSwapThread+0x280
85b58e88 0000001b 00000000 nt!KeWaitForSingleObject+0x249
e151b008 85eb39a0 85a827f8 nt!ExpWaitForResource+0xd3
85a82c2c 00000001 85eb39a0 nt!ExAcquireResourceSharedLite+0xc7
85eb39a0 85a827f8 00000000 Ntfs!NtfsAcquireSharedVcb+0x20
85eb39a0 e151b0d0 e151b008 Ntfs!NtfsCommonClose+0x5a
00000000 00000000 f5db9594 Ntfs!NtfsFspClose+0xe3
857fc008 87014e48 f5db95b4 Ntfs!NtfsCommonCreate+0x132
862d2718 87014e48 87014fd8 Ntfs!NtfsFsdCreate+0x17d
f5fe7bbe f5fe7bbe 867c9004 nt!IovCallDriver+0x110
867c9004 858e9f90 85e2f888 nt!IofCallDriver+0xe
WARNING: Stack unwind information not available. Following frames may be
wrong.
87014e48 f5db9798 87014e48 naiavf5x+0x1bbe
87014e48 00014fd8 008e9f90 naiavf5x+0x6e9d
87014e48 80747a30 85aef4a8 naiavf5x+0x7320
85aef4a8 87014e48 858e9f90 naiavf5x+0x2520
8058f338 8058f338 86914b40 nt!IovCallDriver+0x110
86914b40 8579d524 f5db9990 nt!IofCallDriver+0xe
86914b58 00000000 8579d480 nt!IopParseDevice+0xab5
00000000 f5db9990 00000240 nt!ObpLookupObjectName+0x545
00000000 00000000 ffffff00 nt!ObOpenObjectByName+0xe8
85b03390 80000000 f5db9ba4 nt!IopCreateFile+0x413
85b03390 80000000 f5db9ba4 nt!IoCreateFile+0x3d
85b03390 80000000 f5db9ba4 nt!NtCreateFile+0x2e
85b03390 80000000 f5db9ba4 nt!KiSystemService+0xd0
85b03390 80000000 f5db9ba4 nt!ZwCreateFile+0x11
85993008 80000000 00000003 MyDrv!InCreateFileA+0x158
85993008 00000800 00000003 MyDrv!OPEN_FILE+0xff
f5c3e000 00000000 00000000 MyDrv!OpenAndReadData+0x178
f5c3e000 0d55a000 00000000 MyDrv!ReadData+0x7c7
f5c3e000 0d55a000 00000000 MyDrv!Read+0x29
85ac5b60 867d0760 f5ba9030 MyDrv!ProcessReadRequest+0xc9
85ac5b60 867d0760 00000001 MyDrv!CmdRoutine+0x3b
85aa31b0 00000000 00000000 MyDrv!CmdThreadRoutine+0x1ef
f5b8f7e0 85aa31b0 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 nt!KiThreadStartup+0x16
0: kd> !locks 85a82c2c
Resource @ 0x85a82c2c Exclusively owned
Contention Count = 72
NumberOfSharedWaiters = 17
Threads: 85e882d8-02<*> 867bcc50-01 85a51230-01 86909d18-01
8580ab90-01 85abc350-01 85a88940-01 85e63ae8-01
867b93c8-01 85d4c650-01 85a86460-01 85e60770-01
859bd528-01 85e7e540-01 867bc510-01 85e96b18-01
86909598-01 86909818-01
1 total locks, 1 locks currently held
0: kd> !irp 87014e48
Irp is active with 9 stacks 8 is current (= 0x87014fb4)
No Mdl: No System Buffer: Thread 85e63ae8: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[0, 0] 0 e0 862d2718 858e9f90 f5fe7b50-f5db96c4 Success Error Cancel
\FileSystem\Ntfs naiavf5x
Args: f5db9848 01000862 00030080 00000000
[0, 0] 0 0 85aef4a8 858e9f90 00000000-00000000
\FileSystem\NaiAvFilter1
Args: f5db9848 01000862 00030080 00000000
0: kd> !object 858e9f90
Object: 858e9f90 Type: (868f24b0) File
ObjectHeader: 858e9f78
HandleCount: 0 PointerCount: 1
Directory Object: 00000000 Name: \data\e1a19.dat {HarddiskVolume2}
I have not got any reply. May be the question is stupid. I have got this
deadlock threee times and all these deadlocks have one thing in common.
Ntfs!NtfsCommonClose+0x5a
Ntfs!NtfsFspClose+0xe3
Ntfs!NtfsCommonCreate+0x132
Ntfs!NtfsFsdCreate+0x17d
NTFSFspClose is called after Ntfs!NtfsCommonCreate. what is the meaning of
this. Is this condition holds a special significance. It is not happening
usually that i have checked using debugger. Can any one from you experts
guide me how to avoid this condition.
Rohit,
I think I’d start by making sure that IRPs which are targetted at your
device (VVolume0{05d460a6-0a78-11dc-90b}) are serviced by it. You appear to
have sent an IRP to NTFS for which IrpSp->FileObject->Device is pointing to
your device. A hang is probably the most benign thing that I’d expect at
this point.
If you are going to be playing with layering like this you are going to
spend a lot of time reverse engineering.
Rod
Hi Rohit,
One way to get a clue is to check the ifskit/fastfat source. I see one case
where we might call FspClose(Vcb) from CommonCreate(). I believe that in
that case the FCB you are closing is not related to the file that you are
opening.
In your original email you have:
0: kd> !locks 85a82c2c
Resource @ 0x85a82c2c Exclusively owned
Contention Count = 72
NumberOfSharedWaiters = 17
Threads: 85e882d8-02<*> 867bcc50-01 85a51230-01 86909d18-01
8580ab90-01 85abc350-01 85a88940-01 85e63ae8-01
867b93c8-01 85d4c650-01 85a86460-01 85e60770-01
859bd528-01 85e7e540-01 867bc510-01 85e96b18-01
86909598-01 86909818-01
1 total locks, 1 locks currently held
The create/close thread is just 1 of 17 threads that is waiting for the VCB
shared lock. You need to concentrate on thread 85e882d8 that is holding the
lock exclusive.
The stack trace indicates that we are taking the VCB exclusive and then
waiting for disk i/o to complete.
This does look like a valid scenario for raw volume reads (fast fat seems to
be doing something similar). How long is this thread blocked waiting for
disk completion.
Can you please provide more details on how you concluded that the same VCB
represents 2 different volumes ?
Sara
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rohit
Sent: Monday, June 25, 2007 6:18 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] VCB causes deadlock
I have not got any reply. May be the question is stupid. I have got this
deadlock threee times and all these deadlocks have one thing in common.
Ntfs!NtfsCommonClose+0x5a
Ntfs!NtfsFspClose+0xe3
Ntfs!NtfsCommonCreate+0x132
Ntfs!NtfsFsdCreate+0x17d
NTFSFspClose is called after Ntfs!NtfsCommonCreate. what is the meaning of
this. Is this condition holds a special significance. It is not happening
usually that i have checked using debugger. Can any one from you experts
guide me how to avoid this condition.
— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed to
ntfsd as: xxxxx@symantec.com To unsubscribe send a blank email to
xxxxx@lists.osr.com