Tony,
Thank you for you answer. My filter just forwards the request to the
lower driver in FastIO.
DriverIOWrite ( …
Attached = DeviceExtension->AttachedDevice;
if (Attached) {
FastIoDispatch = Attached->DriverObject->FastIoDispatch;
if (VALID_FAST_IO_DISPATCH_HANDLER( FastIoDispatch, FastIoWrite
))
{
return ( FastIoDispatch->FastIoWrite)( FileObject,
FileOffset,
Length, Wait, LockKey, Buffer, IoStatus, Attached);
}
}
return FALSE;
}
This occurs for all the FastIO functions but the DriverIOQueryOpen where
I simply return FALSE.
I tried also to return FALSE in all FastIO functions, but I have the
same problem.
I don’t call FsRtlRegisterFileSystemFilterCallbacks in my DriverEntry
because I understood it is not required. I don’t set ReleaseForModWrite
in FAST_IO_DISPATCH.
RtlZeroMemory( FastIoDispatch, sizeof( FAST_IO_DISPATCH ) );
FastIoDispatch->SizeOfFastIoDispatch = sizeof( FAST_IO_DISPATCH );
FastIoDispatch->FastIoCheckIfPossible = DriverIOCheckIfPossible;
FastIoDispatch->FastIoRead = DriverIORead;
FastIoDispatch->FastIoWrite = DriverIOWrite;
FastIoDispatch->FastIoQueryBasicInfo = DriverIOQueryBasicInfo;
FastIoDispatch->FastIoQueryStandardInfo = DriverIOQueryStandardInfo;
FastIoDispatch->FastIoLock = DriverIOLock;
FastIoDispatch->FastIoUnlockSingle = DriverIOUnlockSingle;
FastIoDispatch->FastIoUnlockAll = DriverIOUnlockAll;
FastIoDispatch->FastIoUnlockAllByKey = DriverIOUnlockAllByKey;
FastIoDispatch->FastIoDeviceControl = DriverIODeviceControl;
FastIoDispatch->FastIoDetachDevice = DriverIODetachDevice;
FastIoDispatch->FastIoQueryNetworkOpenInfo =
DriverIOQueryNetworkOpenInfo;
FastIoDispatch->MdlRead = DriverIOMdlRead;
FastIoDispatch->MdlReadComplete = DriverIOMdlReadComplete;
FastIoDispatch->PrepareMdlWrite = DriverIOPrepareMdlWrite;
FastIoDispatch->MdlWriteComplete = DriverIOMdlWriteComplete;
FastIoDispatch->FastIoReadCompressed = DriverIOReadCompressed;
FastIoDispatch->FastIoWriteCompressed = DriverIOWriteCompressed;
FastIoDispatch->MdlReadCompleteCompressed =
DriverIOMdlReadCompleteCompressed;
FastIoDispatch->MdlWriteCompleteCompressed =
DriverIOMdlWriteCompleteCompressed;
FastIoDispatch->FastIoQueryOpen = DriverIOQueryOpen;
DriverObject->FastIoDispatch = FastIoDispatch;
So I don’t think I am managing ReleaseForModWrite at all.
May be here is the problem!!
Even though I solve the problem with the lock (and I have to solve it)
I still have a STATUS_FILE_LOCK_CONFLICK.
I believed the problem depends on asynchronous IO. I checked the normal
flow when my driver is disabled and I found the FS always returns a
STATUS_PENDING in the write that causes the problem.
Instead my filter creates a own IRP that returns only later with
STATUS_FILE_LOCK_CONFLICT.
A good policy is to reproduce the normal behavior as much as possible.
Do
you think I should return STATUS_PENDING and start a work thread
whenever
I receive an asynchronous request?
Thank you very much for your hints.
Francesco
What is your filter’s implementation of the fast I/O and/or filter
callback function ReleaseFileForModWrite? That’s where the problem
appears to arise, since a lock that isn’t held is being released.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Francesco Garelli
Sent: Friday, November 11, 2005 3:48 PM
To: ntfsd redirect
Subject: [ntfsd] File System and Cache Manager write at the same time
-> STATUS_FILE_LOCK_CONFLICT and
Hi all,
I am writing the usual file filter to crypt some data. My
implementation works pretty good but with
very heavy I/O, such as EDonkey, the driver crashes. This occurs when
an asynchrous IRP_MJ_WRITE from the
file system and a IRP_MJ_WRITE from the cache manager are concurrent.
When I receive a IRP_MJ_WRITE when I find the IRP_NOCACHE:
- I stop the normal IRP processing
- I know I cannot crypt the original buffer but I have to create a
new one. Anyway to reduce memory fragmentation,
I allocate only a buffer 8 Kb large with
ExAllocateFromNPagedLookasideList.
- I split the user buffer in pieces 8 KB large. For each piece, I
crypt the data to my own buffer, I create a IRP and
I send the request to the lower driver. Then I wait for a
synchronization event.
- In the completion routine I signal the event and I return
STATUS_MORE_PROCESSING_REQUIRE.
- When I receive the event, I repeat the procedure for the next piece
until I write all the user buffer.
- After the last piece, I call IoCompleteRequest for the original IRP
and I return STATUS_SUCCESS.
When I get an error from the lower driver:
- I return the error, if I sent the first piece
- I return STATUS_SUCCESS and I set the IoStatus.Information to the
amount of data I successfully wrote.
Lookin at the log seems that:
- The modified page writer sends a asynchnorous request to my filter-
(Irp->Flags is IRP_NOCACHE | IRP_PAGING_IO)
WRITE(810F37C0): IoGetTopLevelIrp 00000003
WRITE(810F37C0): AllocationSize 7747584 FileSize 7747584
ValidDataLength 4096
WRITE(810F37C0): flag 3 offset 7536640 size 24576
WRITE(810F37C0): writing block size 8192 block size 8192 offset
7536640 WRITE(810F37C0): event for block write is FC93AAA8
-
The operation suspends and the next line in the log is a request
from the file system (IoGetTopLevelIrp returns a
pointer to the current IRP). This request has the flag
IRP_SYNCHRONOUS_API set.
WRITE(810F37C0): IoGetTopLevelIrp FC93AA3C
WRITE(810F37C0): AllocationSize 7747584 FileSize 7747584
ValidDataLength 4096
WRITE(810F37C0): flag 43 offset 4096 size 524288
-
This operation completes succesfully. I split it in 64 requests to
the lower driver. Then the filter receives a similar requests from the
file system. The last before crash is:
WRITE(810F37C0): IoGetTopLevelIrp FC93AA3C
WRITE(810F37C0): AllocationSize 7747584 FileSize 7747584
ValidDataLength 4096
WRITE(810F37C0): flag 43 offset 3674112 size 524288
WRITE(810F37C0): writing block size 8192 block size 8192 offset
3674112 WRITE(810F37C0): event for block write is FC93A414
WRITE(00000000): exit from block completion, event FC93A414, thread
812ADDA8, irql 0, top irp FC93AA3C
WRITE(810F37C0): writing block size 8192 block size 8192 offset
3682304 WRITE(810F37C0): event for block write is FC93A414
WRITE(00000000): exit from block completion, event FC93A414, thread
812ADDA8, irql 0, top irp FC93AA3C
-
Then when the filter is writing the last block, the asynchronous
request completes with STATUS_FILE_LOCK_CONFLICT
and the system crashes due to a bugcheck
WRITE(810F37C0): writing block size 8192 block size 8192 offset
4190208 WRITE(810F37C0): event for block write is FC93A414
WRITE(00000000): exit from block completion, event FC93A414, thread
812ADDA8, irql 0, top irp FC93AA3C
WRITE(00000000): exit from block completion, event FC93AAA8, thread
812ADDA8, irql 0, top irp 00000003
WRITE(810F37C0): cannot write block cause STATUS_FILE_LOCK_CONFLICT
WRITE(810F37C0): cannot write block size 8192 offset 7536640 cause
STATUS_FILE_LOCK_CONFLICT
Below you can find the stacktrace. I see the problem occurs when the
cache manager tries to flush the file. I found
in a previous osr message, this may depend on a resource not released
as expected.
Where am I wrong? Could you help me?
Thanks
Francesco
Use !analyze -v to get detailed debugging information.
BugCheck E3, {ff603150, 812adda8, 0, 2}
Probably caused by : ntoskrnl.exe ( nt!ExReleaseResourceLite+114 )
Followup: MachineOwner
nt!RtlpBreakWithStatusInstruction:
804e3b25 cc int 3
kd> !analyze -v
**********************************************************************
*
* *******
*
*
* Bugcheck Analysis
*
*
*
**********************************************************************
*
* *******
RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: ff603150, Address of resource
Arg2: 812adda8, Address of thread
Arg3: 00000000, Address of owner table if there is one
Arg4: 00000002
Debugging Details:
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xE3
LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25
STACK_TEXT:
fc93a758 805328e7 00000003 fc93aab4 00000000
nt!RtlpBreakWithStatusInstruction
fc93a7a4 805333be 00000003 8115b770 00000001
nt!KiBugCheckDebugBreak+0x19
fc93ab84 805339ae 000000e3 ff603150 812adda8 nt!KeBugCheck2+0x574
fc93aba4 80527b4e 000000e3 ff603150 812adda8 nt!KeBugCheckEx+0x1b
fc93abc8 80501db0 ffa6bc50 00000000 806ee2d0
nt!ExReleaseResourceLite+0x114
fc93ad10 80501e1d 810f37c0 ff603150 810f37c0
nt!FsRtlReleaseFileForModWrite+0x161
fc93ad48 80517a67 00006000 ffa6bc50 00000000 nt!MiWriteComplete+0x266
fc93ad68 805020e7 810f3705 ffbdf428 81267ad0
nt!IoAsynchronousPageWrite+0xdf
fc93adac 8057dfed 00000000 00000000 00000000
nt!MiMappedPageWriter+0xc9 fc93addc 804fa477 8050202a 00000000
00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
nt!ExReleaseResourceLite+114
80527b4e cc int 3
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!ExReleaseResourceLite+114
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 41108004
STACK_COMMAND: kb
BUCKET_ID: 0xE3_nt!ExReleaseResourceLite+114
Followup: MachineOwner
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
------_=_NextPart_001_01C5E7E0.520E0BBC
> xmlns:o=“urn:schemas-microsoft-com:office:office”
xmlns:w=“urn:schemas-microsoft-com:office:word”
xmlns=“http://www.w3.org/TR/REC-html40”>
>
>
> style=‘font-size: 10.0pt;font-family:Arial;color:navy’>What is your
> filter’s implementation of the fast I/O and/or filter callback
> function ReleaseFileForModWrite? That’s where the problem
> appears to arise, since a lock that isn’t held is being
> released.<o:p></o:p>
> style=‘font-size:
> 10.0pt;font-family:Arial;color:navy’><o:p> </o:p>
>
> style=‘font-size:
> 10.0pt;font-family:Arial;color:navy’>Regards,<o:p></o:p>
<
/p>
> style=‘font-size:
> 10.0pt;font-family:Arial;color:navy’><o:p> </o:p>
>
> style=‘font-size:
> 10.0pt;font-family:Arial;color:navy’>Tony<o:p></o:p>
> style=‘font-size:
> 10.0pt;font-family:Arial;color:navy’><o:p> </o:p>
>
> style=‘font-size: 10.0pt;font-family:Arial’>Tony
> Mason<o:p></o:p>
> style=‘font-size: 10.0pt;font-family:Arial’>Consulting
> Partner<o:p></o:p>
> style=‘font-size: 10.0pt;font-family:Arial’>OSR Open Systems
> Resources, Inc.<o:p></o:p>
> style=‘font-size: 10.0pt;font-family:Arial’>> href=“http://www.osr.com”>http://www.osr.com<o:p>
> p></o:p>
> style=‘font-size:12.0pt’> <o:p></o:p>
> size=3 color=black face=“Times New Roman”>> style=‘font-size:12.0pt;color:windowtext’>
>
>
>
>
> style=‘font-size:10.0pt;font-family:Tahoma;color:windowtext;font-
weight
> :bold’>From: > face=Tahoma> xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] > style=‘font-weight:bold’>On Behalf Of Francesco Garelli
> Sent: Friday, November
> 11, 2005 3:48 PM
> To: ntfsd redirect
> Subject: [ntfsd] File
> System and Cache Manager write at the same time ->
> STATUS_FILE_LOCK_CONFLICT and> style=‘color:windowtext’><o:p></o:p>
> style=‘font-size:12.0pt’><o:p> </o:p>
Hi all,
>
> I am writing the usual file filter to crypt some data. My
> implementation works pretty good but with
> very heavy I/O, such as EDonkey, the driver crashes. This occurs when
> an asynchrous IRP_MJ_WRITE from the
> file system and a IRP_MJ_WRITE from the cache manager are
> concurrent.
> When I receive a IRP_MJ_WRITE when I find the IRP_NOCACHE:
> 1) I stop the normal IRP processing
> 2) I know I cannot crypt the original buffer but I have to create a
> new one. Anyway to reduce memory fragmentation,
> I allocate only a buffer 8 Kb large with
> ExAllocateFromNPagedLookasideList.
3) I split the user buffer in
> pieces 8 KB large. For each piece, I crypt the data to my own buffer,
> I create a IRP and
I send the request to the lower driver. Then I
> wait for a synchronization event.
> 4) In the completion routine I signal the event and I return
> STATUS_MORE_PROCESSING_REQUIRE.
> 5) When I receive the event, I repeat the procedure for the next piece
> until I write all the user buffer.
> 6) After the last piece, I call IoCompleteRequest for the original IRP
> and I return STATUS_SUCCESS.
>
> When I get an error from the lower driver:
> 1) I return the error, if I sent the first piece
> 2) I return STATUS_SUCCESS and I set the IoStatus.Information to the
> amount of data I successfully wrote.
>
>
> Lookin at the log seems that:
>
> 1) The modified page writer sends a asynchnorous request to my filter-
> (Irp->Flags is IRP_NOCACHE | IRP_PAGING_IO)
>
> WRITE(810F37C0): IoGetTopLevelIrp 00000003
> WRITE(810F37C0): AllocationSize 7747584 FileSize 7747584
> ValidDataLength 4096
WRITE(810F37C0): flag 3 offset 7536640 size
> 24576
WRITE(810F37C0): writing block size 8192 block size 8192
> offset 7536640
WRITE(810F37C0): event for block write is
> FC93AAA8
> 2) The operation suspends and the next line in the log is a request
> from the file system (> style=‘font-weight:bold’>IoGetTopLevelIrp returns a
> pointer to the current IRP). This request has the flag
> IRP_SYNCHRONOUS_API set.
WRITE(810F37C0): IoGetTopLevelIrp
> FC93AA3C
WRITE(810F37C0): AllocationSize 7747584 FileSize 7747584
> ValidDataLength 4096
WRITE(810F37C0): flag 43 offset 4096 size
> 524288
> 3) This operation completes succesfully. I split it in 64 requests to
> the lower driver. Then the filter receives a similar requests from
> the
file system. The last before crash is:
> WRITE(810F37C0): IoGetTopLevelIrp FC93AA3C
> WRITE(810F37C0): AllocationSize 7747584 FileSize 7747584
> ValidDataLength 4096
WRITE(810F37C0): flag 43 offset 3674112 size
> 524288
WRITE(810F37C0): writing block size 8192 block size 8192
> offset 3674112
WRITE(810F37C0): event for block write is
> FC93A414
WRITE(00000000): exit from block completion, event
> FC93A414, thread 812ADDA8, irql 0, top irp FC93AA3C
> WRITE(810F37C0): writing block size 8192 block size 8192 offset
> 3682304
WRITE(810F37C0): event for block write is FC93A414
> WRITE(00000000): exit from block completion, event FC93A414, thread
> 812ADDA8, irql 0, top irp FC93AA3C
>
> 4) Then when the filter is writing the last block, the asynchronous
> request completes with STATUS_FILE_LOCK_CONFLICT
> and the system crashes due to a bugcheck
>
> WRITE(810F37C0): writing block size 8192 block size 8192 offset
> 4190208
WRITE(810F37C0): event for block write is FC93A414
> WRITE(00000000): exit from block completion, event FC93A414, thread
> 812ADDA8, irql 0, top irp FC93AA3C
> WRITE(00000000): exit from block completion, event FC93AAA8, thread
> 812ADDA8, irql 0, top irp 00000003
> WRITE(810F37C0): cannot write block cause
> STATUS_FILE_LOCK_CONFLICT
WRITE(810F37C0): cannot write block size
> 8192 offset 7536640 cause STATUS_FILE_LOCK_CONFLICT
>
> Below you can find the stacktrace. I see the problem occurs when the
> cache manager tries to flush the file. I found
> in a previous osr message, this may depend on a resource not released
> as expected.
> Where am I wrong? Could you help me?
>
> Thanks
> Francesco
>
> ---------------------------------------------------------------
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck E3, {ff603150, 812adda8, 0, 2}
>
> Probably caused by : ntoskrnl.exe ( nt!ExReleaseResourceLite+114 )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 804e3b25
> cc
&nb
> sp; int 3
> kd> !analyze -v
> *************************************************************
>
> *
&nbs
> p;
&nb
> sp;
&n
> bsp;
&
> nbsp;
>
 
> ; *
> *
&nbs
> p;
> Bugcheck
> Analysis
&nb
> sp;
&n
> bsp;
&
> nbsp; *
> *
&nbs
> p;
&nb
> sp;
&n
> bsp;
&
> nbsp;
>
 
> ; *
> *************************************************************
>
> RESOURCE_NOT_OWNED (e3)
> A thread tried to release a resource it did not own.
> Arguments:
> Arg1: ff603150, Address of resource
> Arg2: 812adda8, Address of thread
> Arg3: 00000000, Address of owner table if there is one
> Arg4: 00000002
>
> Debugging Details:
> ------------------
>
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xE3
>
> LAST_CONTROL_TRANSFER: from 805328e7 to 804e3b25
>
> STACK_TEXT:
> fc93a758 805328e7 00000003 fc93aab4 00000000
> nt!RtlpBreakWithStatusInstruction
fc93a7a4 805333be 00000003
> 8115b770 00000001 nt!KiBugCheckDebugBreak+0x19
fc93ab84 805339ae
> 000000e3 ff603150 812adda8 nt!KeBugCheck2+0x574
fc93aba4 80527b4e
> 000000e3 ff603150 812adda8 nt!KeBugCheckEx+0x1b
fc93abc8 80501db0
> ffa6bc50 00000000 806ee2d0 nt!ExReleaseResourceLite+0x114
fc93ad10
> 80501e1d 810f37c0 ff603150 810f37c0
> nt!FsRtlReleaseFileForModWrite+0x161
fc93ad48 80517a67 00006000
> ffa6bc50 00000000 nt!MiWriteComplete+0x266
fc93ad68 805020e7
> 810f3705 ffbdf428 81267ad0 nt!IoAsynchronousPageWrite+0xdf
> fc93adac 8057dfed 00000000 00000000 00000000
> nt!MiMappedPageWriter+0xc9
fc93addc 804fa477 8050202a 00000000
> 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000
> 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> nt!ExReleaseResourceLite+114
> 80527b4e
> cc
&nb
> sp; int 3
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!ExReleaseResourceLite+114
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntoskrnl.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41108004
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0xE3_nt!ExReleaseResourceLite+114
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> <o:p></o:p>
------_=_NextPart_001_01C5E7E0.520E0BBC–