Gentlefolk
I have a quickie question.
Is it supposed to be normal or permissible for FastIoMdlWriteComplete to be
called in the context of a thread which is a shared owner of the
PagingIoResource of the fcb at parameter FileObject->FsContext?
Thanks
Lyndon
It seems answer must be in the affirmative; happens on W2K3 at least.
FastIoMdlWriteComplete <– CcMdlWriteComplete <– NtfsCompleteMdl <–
NtfsFsdWrite <– Irp <– SrvIssueMdlCompleteRequest <–
SrvFsdRestartWriteAndX.
“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Gentlefolk
>
> I have a quickie question.
>
> Is it supposed to be normal or permissible for FastIoMdlWriteComplete to
> be called in the context of a thread which is a shared owner of the
> PagingIoResource of the fcb at parameter FileObject->FsContext?
>
> Thanks
> Lyndon
>
>
>
Amazing.
SRV calls the FSD with locks held. Am I right that SRV can grab the FCB
locks at will directly without using the FSD’s paths?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Lyndon J Clarke”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, November 26, 2004 10:27 PM
Subject: Re:[ntfsd] PagingIo resource held before FastIoMdlWriteComplete called
…
> It seems answer must be in the affirmative; happens on W2K3 at least.
>
> FastIoMdlWriteComplete <– CcMdlWriteComplete <– NtfsCompleteMdl <–
> NtfsFsdWrite <– Irp <– SrvIssueMdlCompleteRequest <–
> SrvFsdRestartWriteAndX.
>
> “Lyndon J Clarke” wrote in message
> news:xxxxx@ntfsd…
> > Gentlefolk
> >
> > I have a quickie question.
> >
> > Is it supposed to be normal or permissible for FastIoMdlWriteComplete to
> > be called in the context of a thread which is a shared owner of the
> > PagingIoResource of the fcb at parameter FileObject->FsContext?
> >
> > Thanks
> > Lyndon
> >
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
It could be that srv has invoked fsd through device stack … fsd has
acquired lock and recursed into fsd through device stack …
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> Amazing.
>
> SRV calls the FSD with locks held. Am I right that SRV can grab the FCB
> locks at will directly without using the FSD’s paths?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Lyndon J Clarke”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, November 26, 2004 10:27 PM
> Subject: Re:[ntfsd] PagingIo resource held before FastIoMdlWriteComplete
> called
> …
>
>
>> It seems answer must be in the affirmative; happens on W2K3 at least.
>>
>> FastIoMdlWriteComplete <– CcMdlWriteComplete <– NtfsCompleteMdl <–
>> NtfsFsdWrite <– Irp <– SrvIssueMdlCompleteRequest <–
>> SrvFsdRestartWriteAndX.
>>
>> “Lyndon J Clarke” wrote in message
>> news:xxxxx@ntfsd…
>> > Gentlefolk
>> >
>> > I have a quickie question.
>> >
>> > Is it supposed to be normal or permissible for FastIoMdlWriteComplete
>> > to
>> > be called in the context of a thread which is a shared owner of the
>> > PagingIoResource of the fcb at parameter FileObject->FsContext?
>> >
>> > Thanks
>> > Lyndon
>> >
>> >
>> >
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
Maxim
Here is the relevant part of the stack trace … when
MyFlt!MyFastIoMdlWriteComplete is called thread is shared owner of
PagingIoResource for fcb for file object at 82e2e4b8.
f545bbf8 806265de 82e2e4b8 82375e08 823b2f88
MyFlt!MyFastIoMdlWriteComplete+0x101 (CONV: stdcall) [–snip–]
f545bc10 f732e854 82e2e4b8 82375e08 823b2f88
nt!CcMdlWriteComplete+0x2d
f545bc74 f72cd6a5 820eb7a8 82375c90 00684140
Ntfs!NtfsCompleteMdl+0x104
f545bce8 804e0e0d 82ea4020 82375c90 82dc2668 Ntfs!NtfsFsdWrite+0xfd
f545bcf8 f5345bc6 82ebcf38 804e0e0d 82dc2668 nt!IofCallDriver+0x3f
(FPO: [0,0,0])
f545bd00 804e0e0d 82dc2668 82375c90 82375c90 MyFlt!MyDispatch+0x2e
(FPO: [2,0,0]) (CONV: stdcall) [–snip–]
f545bd10 f5226c6e 825e3ef0 8265d830 8265e180 nt!IofCallDriver+0x3f
(FPO: [0,0,0])
f545bd3c f526e277 8265d830 82dc2668 823b2f88
srv!SrvIssueMdlCompleteRequest+0xce
f545bd84 f5231c47 00000000 82357958 00000000
srv!SrvFsdRestartWriteAndX+0x575
f545bdac 8059942a 00f1da80 00000000 00000000 srv!WorkerThread+0x136
f545bddc 80500a04 f5231b80 82f1da80 00000000
nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
So just to make life interesting here are some more things which happen at
the same time. We have this thread below; it is waiting to acquire the same
PagingIoResource exclusive. It is at the time shared owner of the relevant
Vcb resource and there are a number of threads waiting to acquire Vcb
resource shared and one thread witing to acquire exclusive.
f78c6768 804e4252 8302dda0 82de4b10 00000000 nt!KiSwapContext+0x25
(FPO: [EBP 0xf78c6780] [0,0,4])
f78c6780 804e42c2 8302dda0 821a9630 00000000 nt!KiSwapThread+0x85
f78c67b0 8050e2d6 82de4b10 0000001b 00000000
nt!KeWaitForSingleObject+0x209
f78c67ec 804ef2ca e18bdcd8 f78c6a1c f78c6a00
nt!ExpWaitForResource+0xd1
f78c67fc f72c2cb8 821a9630 00000001 f72e9fa2
nt!ExAcquireResourceExclusiveLite+0x6c
f78c6808 f72e9fa2 f78c6a1c e18bdcd8 00000001
Ntfs!NtfsAcquirePagingResourceExclusive+0x1d (FPO: [3,0,0])
f78c6a00 f72ea7c1 f78c6a1c 8297c828 82e2e4b8
Ntfs!NtfsCommonCleanup+0x184
f78c6b70 804e0e0d 82ea4020 8297c828 82dc2668
Ntfs!NtfsFsdCleanup+0xcf
f78c6b80 f5345bc6 82ebcf38 804e0e0d 82dc2668 nt!IofCallDriver+0x3f
(FPO: [0,0,0])
f78c6b88 804e0e0d 82dc2668 8297c828 8297c828 MyFlt!MyDispatch+0x2e
(FPO: [2,0,0]) (CONV: stdcall) [–snip–]
f78c6b98 80578b7a 82e2e4a0 83027560 00000001 nt!IofCallDriver+0x3f
(FPO: [0,0,0])
f78c6bc8 8057585d 8302f9b0 82dc2668 0002019f nt!IopCloseFile+0x276
f78c6bf8 805767b3 8302f9b0 82e2e4b8 83027560
nt!ObpDecrementHandleCount+0x11d
f78c6c20 8057681d e1000d58 82e2e4b8 00000afc
nt!ObpCloseHandleTableEntry+0x12f
f78c6c64 80576864 00000afc 00000000 f5236711 nt!ObpCloseHandle+0x80
f78c6c70 f5236711 00000afc 82e2b2a0 e198ac48 nt!NtClose+0x17 (FPO:
[1,0,0])
f78c6c80 f523643a 00000afc 00000001 8266a4d0 srv!SrvNtClose+0x24
(FPO: [2,0,0])
f78c6c94 f526d1e1 82e2b2a0 80717cd0 82e2b2a0
srv!UnlinkRfcbFromLfcb+0x49 (FPO: [1,0,0])
f78c6cb0 f526d058 82e2b2a0 80717cd0 8266a4d0
srv!SrvCompleteRfcbClose+0x172
f78c6cd0 f5225432 82e2b2a0 e1258500 8266a4d0
srv!CloseRfcbInternal+0xb4
f78c6cf4 f5254c10 e1258500 00000000 e1258530
srv!SrvCloseRfcbsOnSessionOrPid+0x72
f78c6d10 f524dfe7 e1258530 f522eeb4 8266a4d0
srv!SrvCloseSession+0x60 (FPO: [EBP 0xf78c6d34] [1,0,0])
f78c6d34 f52250f3 00000000 00000000 f522f0a4
srv!SrvCloseSessionsOnConnection+0xa7
f78c6d50 f522796d 8266a4d0 00000001 8302dda0
srv!SrvCloseConnection+0xf3
f78c6d6c f52237a4 805702e0 f522f0c8 01000000
srv!ProcessConnectionDisconnects+0x7d (FPO: [EBP 0xf78c6d80] [0,0,0])
f78c6d80 804ec5f0 00000000 00000000 8302dda0
srv!SrvResourceThread+0x24
f78c6dac 8059942a 00000000 00000000 00000000 nt!ExpWorkerThread+0xe9
f78c6ddc 80500a04 804ec535 00000000 00000000
nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
Now just to make life even more interesting one of the threads waiting to
acquire Vcb shared is under NtFlushKey and has passed CmpLockRegistry and
holds resource CmpRegistryLock shared. There are also five threads waiting
to acquire CmpRegistryLock exclusive and a couple of dozen threads waiting
to acquire CmpRegistryLock shared. The system seems to be in a somewhat
perilous state with high risk of deadlock and imminent total failure;
FastIoMdlWriteComplete looks (to me at least) very hostile to the filter
driver developer!
Cheers
Lyndon