Cached IO on Memory Mapped File hangs

Hi all,

When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need to zero out the last block in the file. So when the file is memory mapped and i try to perform cached/IO on the same FO, then application hangs indefinitely. Non-cached IOs are fine. Just trying to understand what rule i am breaking here. Here are details

  1. User creates the file and memory maps the files.
  2. This memory map causes system to send IRP_MJ_SET_INFORMATION with SetEOF.

So far no data has been written by the application, as creating the section is causing SETEOF call.

Now i need to align and zero out the last block in the file. No data has been written yet (as i haven’t received any Paging IO). So when i use the same FO to perform the cacheIO, then application hangs indefinitely.

Any idea which rule i am breaking?

Also checking FO_CACHE_SUPPORTED flag for memory map is enough or i will have to track it. As i have only seen this flag set when file is memory mapped, not for regular cached FO.

thanks in advance.

Check if SetFile.AdvanceOnly is set, if so, ignore this – it is not really a set end of file operation. Search the archive for more discussion on this.


From: “xxxxx@gmail.com
To: Windows File Systems Devs Interest List
Sent: Tue, March 2, 2010 3:37:45 PM
Subject: [ntfsd] Cached IO on Memory Mapped File hangs

Hi all,

When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need to zero out the last block in the file. So when the file is memory mapped and i try to perform cached/IO on the same FO, then application hangs indefinitely. Non-cached IOs are fine. Just trying to understand what rule i am breaking here. Here are details

1. User creates the file and memory maps the files.
2. This memory map causes system to send IRP_MJ_SET_INFORMATION with SetEOF.

So far no data has been written by the application, as creating the section is causing SETEOF call.

Now i need to align and zero out the last block in the file. No data has been written yet (as i haven’t received any Paging IO). So when i use the same FO to perform the cacheIO, then application hangs indefinitely.

Any idea which rule i am breaking?

Also checking FO_CACHE_SUPPORTED? flag for memory map is enough or i will have to track it. As i have only seen this flag set when file is memory mapped, not for regular cached FO.

thanks in advance.


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

I am already checking that.

if(PagingIo && AdvanceOnly){
LEAVE;
}

I haven’t found anything specific to this in the archive.

thanks for the answer.

Lijun Wang wrote:

Check if SetFile.AdvanceOnly is set, if so, ignore this – it is not
really a set end of file operation. Search the archive for more
discussion on this.


*From:* “xxxxx@gmail.com
> To: Windows File Systems Devs Interest List
> Sent: Tue, March 2, 2010 3:37:45 PM
> Subject: [ntfsd] Cached IO on Memory Mapped File hangs
>
> Hi all,
>
> When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need to
> zero out the last block in the file. So when the file is memory mapped
> and i try to perform cached/IO on the same FO, then application hangs
> indefinitely. Non-cached IOs are fine. Just trying to understand what
> rule i am breaking here. Here are details
>
> 1. User creates the file and memory maps the files.
> 2. This memory map causes system to send IRP_MJ_SET_INFORMATION with
> SetEOF.
>
> So far no data has been written by the application, as creating the
> section is causing SETEOF call.
>
> Now i need to align and zero out the last block in the file. No data has
> been written yet (as i haven’t received any Paging IO). So when i use
> the same FO to perform the cacheIO, then application hangs indefinitely.
>
> Any idea which rule i am breaking?
>
> Also checking FO_CACHE_SUPPORTED flag for memory map is enough or i
> will have to track it. As i have only seen this flag set when file is
> memory mapped, not for regular cached FO.
>
> thanks in advance.
>
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

APC_LEVEL? SKAPC disabled?

wrote in message news:xxxxx@ntfsd…
> Hi all,
>
> When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need to
> zero out the last block in the file. So when the file is memory mapped and
> i try to perform cached/IO on the same FO, then application hangs
> indefinitely. Non-cached IOs are fine. Just trying to understand what rule
> i am breaking here. Here are details
>
> 1. User creates the file and memory maps the files.
> 2. This memory map causes system to send IRP_MJ_SET_INFORMATION with
> SetEOF.
>
> So far no data has been written by the application, as creating the
> section is causing SETEOF call.
>
> Now i need to align and zero out the last block in the file. No data has
> been written yet (as i haven’t received any Paging IO). So when i use the
> same FO to perform the cacheIO, then application hangs indefinitely.
>
> Any idea which rule i am breaking?
>
> Also checking FO_CACHE_SUPPORTED flag for memory map is enough or i will
> have to track it. As i have only seen this flag set when file is memory
> mapped, not for regular cached FO.
>
> thanks in advance.
>
>
>
>
>

I have already checked that. IRQL is PASSIVE_LEVEL

!irql
Debugger saved IRQL for processor 0x0 – 0 (LOW_LEVEL)

What is SKAPC?

Lyndon J. Clarke wrote:

APC_LEVEL? SKAPC disabled?

wrote in message news:xxxxx@ntfsd…
>> Hi all,
>>
>> When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need
>> to zero out the last block in the file. So when the file is memory
>> mapped and i try to perform cached/IO on the same FO, then application
>> hangs indefinitely. Non-cached IOs are fine. Just trying to understand
>> what rule i am breaking here. Here are details
>>
>> 1. User creates the file and memory maps the files.
>> 2. This memory map causes system to send IRP_MJ_SET_INFORMATION with
>> SetEOF.
>>
>> So far no data has been written by the application, as creating the
>> section is causing SETEOF call.
>>
>> Now i need to align and zero out the last block in the file. No data
>> has been written yet (as i haven’t received any Paging IO). So when i
>> use the same FO to perform the cacheIO, then application hangs
>> indefinitely.
>>
>> Any idea which rule i am breaking?
>>
>> Also checking FO_CACHE_SUPPORTED flag for memory map is enough or i
>> will have to track it. As i have only seen this flag set when file is
>> memory mapped, not for regular cached FO.
>>
>> thanks in advance.
>>
>>
>>
>>
>>
>

Special Kernel APC’s.

mm

You probably want to paste your code snippet around this?to give us more context. Also, try !locks and !process 0 7 to understand the nature of the hang.

Lijun


From: Rajesh Gupta
To: Windows File Systems Devs Interest List
Sent: Tue, March 2, 2010 7:57:23 PM
Subject: Re:[ntfsd] Cached IO on Memory Mapped File hangs

I have already checked that. IRQL is PASSIVE_LEVEL

!irql
Debugger saved IRQL for processor 0x0 – 0 (LOW_LEVEL)

What is SKAPC?

Lyndon J. Clarke wrote:
> APC_LEVEL? SKAPC disabled?
>
> wrote in message news:xxxxx@ntfsd…
>> Hi all,
>>
>> When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need to zero out the last block in the file. So when the file is memory mapped and i try to perform cached/IO on the same FO, then application hangs indefinitely. Non-cached IOs are fine. Just trying to understand what rule i am breaking here. Here are details
>>
>> 1. User creates the file and memory maps the files.
>> 2. This memory map causes system to send IRP_MJ_SET_INFORMATION with SetEOF.
>>
>> So far no data has been written by the application, as creating the section is causing SETEOF call.
>>
>> Now i need to align and zero out the last block in the file. No data has been written yet (as i haven’t received any Paging IO). So when i use the same FO to perform the cacheIO, then application hangs indefinitely.
>>
>> Any idea which rule i am breaking?
>>
>> Also checking FO_CACHE_SUPPORTED? flag for memory map is enough or i will have to track it. As i have only seen this flag set when file is memory mapped, not for regular cached FO.
>>
>> thanks in advance.
>>
>>
>>
>>
>>
>


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

I did some more research and found out the following…
vmmfiltr
As the SETEOF was called because user created the Section. I am trying
to perform the cached IO, which also initiated the MmCreateSection as
data is not in the memory. This create section holds the locks
exclusively… Hence it hangs… Seems like my only option is to perform
the direct IO here…

!locks
Resource @ 0xfffffadffea152d0 Exclusively owned
Threads: fffffadffe95e040-02<*>
KD: Scanning for held locks…

Resource @ 0xfffffadffeeb3ac0 Exclusively owned
Threads: fffffadffe95e040-01<*>
KD: Scanning for held locks…
18178 total locks, 2 locks currently held

fffffadfe0ef3330 fffff80001027852 nt!KiSwapContext+0x85
fffffadfe0ef34b0 fffff8000102845e nt!KiSwapThread+0x3c9
fffffadfe0ef3510 fffff8000109023c nt!KeWaitForSingleObject+0x5a6
fffffadfe0ef3590 fffff8000103bd8b nt!MmCreateSection+0x6b8
fffffadfe0ef3700 fffffadfe3d04068 nt!CcInitializeCacheMap+0x456
fffffadfe0ef37c0 fffffadfe3d0231a Ntfs!NtfsCommonWrite+0x2674
fffffadfe0ef3aa0 fffff800013e3255 Ntfs!NtfsFsdWrite+0x2e4
fffffadfe0ef3b70 fffffadfe3f8e542 nt!IovCallDriver+0x1b5
fffffadfe0ef3be0 fffffadfe3f8f890
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
fffffadfe0ef3c50 fffffadfe3f8ffdb fltmgr!FltPerformSynchronousIo+0x1b0
fffffadfe0ef3cc0 fffffadfe3e547ee fltmgr!FltWriteFile+0x18b
fffffadfe0ef3d40 fffffadfe3e4e495
vmfiltr!VmDDirectIoWriteCluster+0x33e
[c:\main\fspem\agent\fs\windows\vfiltr\src\utils.cpp @ 99]
fffffadfe0ef3dd0 fffffadfe3e5309b
vmfiltr!ReadWriteUnalignedBlock+0xf55
[c:\main\fspem\agent\fs\windows\vfiltr\src\release.cpp @ 281]
fffffadfe0ef3f00 fffffadfe3e4f284 vmfiltr!PostSetEofInfo+0x85b
[c:\main\fspem\agent\fs\windows\vfiltr\src\seteofinfo.cpp @ 411]
fffffadfe0ef4050 fffffadfe3e4925a vmfiltr!PostSetInfo+0x84
[c:\main\fspem\agent\fs\windows\vfiltr\src\setinfo.cpp @ 136]
fffffadfe0ef4100 fffffadfe3e49498 vmfiltr!PostCallOp+0x5a
[c:\main\fspem\agent\fs\windows\vfiltr\src\postop.cpp @ 47]
fffffadfe0ef4140 fffffadfe3fbb629 vmfiltr!PostOp+0xf8
[c:\main\fspem\agent\fs\windows\vfiltr\src\postop.cpp @ 109]
fffffadfe0ef41a0 fffffadfe3f88f96 fltmgr!FltvPostOperation+0x79
fffffadfe0ef41d0 fffffadfe3f8d7c7 fltmgr!FltpPerformPostCallbacks+0x286
fffffadfe0ef4290 fffff800013e398b fltmgr!FltpPassThroughCompletion+0xe7
fffffadfe0ef42e0 fffff80001025466 nt!IovpLocalCompletionRoutine+0xfb
fffffadfe0ef4330 fffff800013e3838 nt!IopfCompleteRequest+0x117
fffffadfe0ef43a0 fffffadfe3d053f3 nt!IovCompleteRequest+0x1d8
fffffadfe0ef4480 fffffadfe3d7a1d2 Ntfs!NtfsCompleteRequest+0xdc
fffffadfe0ef44b0 fffffadfe3d01555 Ntfs!NtfsCommonSetInformation+0x7b6
fffffadfe0ef4550 fffff800013e3255 Ntfs!NtfsFsdSetInformation+0x1de
fffffadfe0ef4600 fffffadfe3f8e542 nt!IovCallDriver+0x1b5
fffffadfe0ef4670 fffffadfe3f8e8df
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
fffffadfe0ef46e0 fffff800013e3255 fltmgr!FltpDispatch+0x17f
fffffadfe0ef4740 fffffadfe3f8e542 nt!IovCallDriver+0x1b5
fffffadfe0ef47b0 fffffadfe3f8e8df
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
fffffadfe0ef4820 fffff800013e3255 fltmgr!FltpDispatch+0x17f
fffffadfe0ef4880 fffff80001308319 nt!IovCallDriver+0x1b5
fffffadfe0ef48f0 fffff800012ba210 nt!FsRtlSetFileSize+0xd9
fffffadfe0ef4960 fffff80001047310 nt!MiCreateDataFileMap+0x96
fffffadfe0ef49f0 fffff8000129ed2e nt!MmCreateSection+0xaee
fffffadfe0ef4b60 fffff8000102e63d nt!NtCreateSection+0x177
fffffadfe0ef4c00 0000000077ef0e8a nt!KiSystemServiceCopyEnd+0x3
000000000012f448 0000000000000000 0x77ef0e8a

Lijun Wang wrote:

You probably want to paste your code snippet around this to give us more
context. Also, try !locks and !process 0 7 to understand the nature of
the hang.

Lijun

*From:* Rajesh Gupta
> To: Windows File Systems Devs Interest List
> Sent: Tue, March 2, 2010 7:57:23 PM
> Subject: Re:[ntfsd] Cached IO on Memory Mapped File hangs
>
> I have already checked that. IRQL is PASSIVE_LEVEL
>
> !irql
> Debugger saved IRQL for processor 0x0 – 0 (LOW_LEVEL)
>
> What is SKAPC?
>
> Lyndon J. Clarke wrote:
> > APC_LEVEL? SKAPC disabled?
> >
> > > wrote in message
> news:xxxxx@ntfsd…
> >> Hi all,
> >>
> >> When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need
> to zero out the last block in the file. So when the file is memory
> mapped and i try to perform cached/IO on the same FO, then application
> hangs indefinitely. Non-cached IOs are fine. Just trying to understand
> what rule i am breaking here. Here are details
> >>
> >> 1. User creates the file and memory maps the files.
> >> 2. This memory map causes system to send IRP_MJ_SET_INFORMATION with
> SetEOF.
> >>
> >> So far no data has been written by the application, as creating the
> section is causing SETEOF call.
> >>
> >> Now i need to align and zero out the last block in the file. No data
> has been written yet (as i haven’t received any Paging IO). So when i
> use the same FO to perform the cacheIO, then application hangs indefinitely.
> >>
> >> Any idea which rule i am breaking?
> >>
> >> Also checking FO_CACHE_SUPPORTED flag for memory map is enough or i
> will have to track it. As i have only seen this flag set when file is
> memory mapped, not for regular cached FO.
> >>
> >> thanks in advance.
> >>
> >>
> >>
> >>
> >>
> >
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Rajesh, what is TopLevelIrp?

“Rajesh Gupta” wrote in message news:xxxxx@ntfsd…
> I did some more research and found out the following…
> vmmfiltr
> As the SETEOF was called because user created the Section. I am trying to
> perform the cached IO, which also initiated the MmCreateSection as data is
> not in the memory. This create section holds the locks exclusively…
> Hence it hangs… Seems like my only option is to perform the direct IO
> here…
>
> !locks
> Resource @ 0xfffffadffea152d0 Exclusively owned
> Threads: fffffadffe95e040-02<>
> KD: Scanning for held locks…
>
> Resource @ 0xfffffadffeeb3ac0 Exclusively owned
> Threads: fffffadffe95e040-01<
>
> KD: Scanning for held locks…
> 18178 total locks, 2 locks currently held
>
>
>
>
> fffffadfe0ef3330 fffff80001027852 nt!KiSwapContext+0x85
> fffffadfe0ef34b0 fffff8000102845e nt!KiSwapThread+0x3c9
> fffffadfe0ef3510 fffff8000109023c nt!KeWaitForSingleObject+0x5a6
> fffffadfe0ef3590 fffff8000103bd8b nt!MmCreateSection+0x6b8
> fffffadfe0ef3700 fffffadfe3d04068 nt!CcInitializeCacheMap+0x456
> fffffadfe0ef37c0 fffffadfe3d0231a Ntfs!NtfsCommonWrite+0x2674
> fffffadfe0ef3aa0 fffff800013e3255 Ntfs!NtfsFsdWrite+0x2e4
> fffffadfe0ef3b70 fffffadfe3f8e542 nt!IovCallDriver+0x1b5
> fffffadfe0ef3be0 fffffadfe3f8f890
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
> fffffadfe0ef3c50 fffffadfe3f8ffdb fltmgr!FltPerformSynchronousIo+0x1b0
> fffffadfe0ef3cc0 fffffadfe3e547ee fltmgr!FltWriteFile+0x18b
> fffffadfe0ef3d40 fffffadfe3e4e495 vmfiltr!VmDDirectIoWriteCluster+0x33e
> [c:\main\fspem\agent\fs\windows\vfiltr\src\utils.cpp @ 99]
> fffffadfe0ef3dd0 fffffadfe3e5309b vmfiltr!ReadWriteUnalignedBlock+0xf55
> [c:\main\fspem\agent\fs\windows\vfiltr\src\release.cpp @ 281]
> fffffadfe0ef3f00 fffffadfe3e4f284 vmfiltr!PostSetEofInfo+0x85b
> [c:\main\fspem\agent\fs\windows\vfiltr\src\seteofinfo.cpp @ 411]
> fffffadfe0ef4050 fffffadfe3e4925a vmfiltr!PostSetInfo+0x84
> [c:\main\fspem\agent\fs\windows\vfiltr\src\setinfo.cpp @ 136]
> fffffadfe0ef4100 fffffadfe3e49498 vmfiltr!PostCallOp+0x5a
> [c:\main\fspem\agent\fs\windows\vfiltr\src\postop.cpp @ 47]
> fffffadfe0ef4140 fffffadfe3fbb629 vmfiltr!PostOp+0xf8
> [c:\main\fspem\agent\fs\windows\vfiltr\src\postop.cpp @ 109]
> fffffadfe0ef41a0 fffffadfe3f88f96 fltmgr!FltvPostOperation+0x79
> fffffadfe0ef41d0 fffffadfe3f8d7c7 fltmgr!FltpPerformPostCallbacks+0x286
> fffffadfe0ef4290 fffff800013e398b fltmgr!FltpPassThroughCompletion+0xe7
> fffffadfe0ef42e0 fffff80001025466 nt!IovpLocalCompletionRoutine+0xfb
> fffffadfe0ef4330 fffff800013e3838 nt!IopfCompleteRequest+0x117
> fffffadfe0ef43a0 fffffadfe3d053f3 nt!IovCompleteRequest+0x1d8
> fffffadfe0ef4480 fffffadfe3d7a1d2 Ntfs!NtfsCompleteRequest+0xdc
> fffffadfe0ef44b0 fffffadfe3d01555 Ntfs!NtfsCommonSetInformation+0x7b6
> fffffadfe0ef4550 fffff800013e3255 Ntfs!NtfsFsdSetInformation+0x1de
> fffffadfe0ef4600 fffffadfe3f8e542 nt!IovCallDriver+0x1b5
> fffffadfe0ef4670 fffffadfe3f8e8df
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
> fffffadfe0ef46e0 fffff800013e3255 fltmgr!FltpDispatch+0x17f
> fffffadfe0ef4740 fffffadfe3f8e542 nt!IovCallDriver+0x1b5
> fffffadfe0ef47b0 fffffadfe3f8e8df
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3f2
> fffffadfe0ef4820 fffff800013e3255 fltmgr!FltpDispatch+0x17f
> fffffadfe0ef4880 fffff80001308319 nt!IovCallDriver+0x1b5
> fffffadfe0ef48f0 fffff800012ba210 nt!FsRtlSetFileSize+0xd9
> fffffadfe0ef4960 fffff80001047310 nt!MiCreateDataFileMap+0x96
> fffffadfe0ef49f0 fffff8000129ed2e nt!MmCreateSection+0xaee
> fffffadfe0ef4b60 fffff8000102e63d nt!NtCreateSection+0x177
> fffffadfe0ef4c00 0000000077ef0e8a nt!KiSystemServiceCopyEnd+0x3
> 000000000012f448 0000000000000000 0x77ef0e8a
>
>
> Lijun Wang wrote:
>>
>> You probably want to paste your code snippet around this to give us more
>> context. Also, try !locks and !process 0 7 to understand the nature of
>> the hang.
>> Lijun
>> ------------------------------------------------------------------------
>> From: Rajesh Gupta
>> To: Windows File Systems Devs Interest List
>> Sent: Tue, March 2, 2010 7:57:23 PM
>> Subject: Re:[ntfsd] Cached IO on Memory Mapped File hangs
>>
>> I have already checked that. IRQL is PASSIVE_LEVEL
>>
>> !irql
>> Debugger saved IRQL for processor 0x0 – 0 (LOW_LEVEL)
>>
>> What is SKAPC?
>>
>> Lyndon J. Clarke wrote:
>> > APC_LEVEL? SKAPC disabled?
>> >
>> > > wrote in message
>> news:xxxxx@ntfsd…
>> >> Hi all,
>> >>
>> >> When i receive IRP_MJ_SET_INFORMATION with SetEOF information i need
>> to zero out the last block in the file. So when the file is memory mapped
>> and i try to perform cached/IO on the same FO, then application hangs
>> indefinitely. Non-cached IOs are fine. Just trying to understand what
>> rule i am breaking here. Here are details
>> >>
>> >> 1. User creates the file and memory maps the files.
>> >> 2. This memory map causes system to send IRP_MJ_SET_INFORMATION with
>> SetEOF.
>> >>
>> >> So far no data has been written by the application, as creating the
>> section is causing SETEOF call.
>> >>
>> >> Now i need to align and zero out the last block in the file. No data
>> has been written yet (as i haven’t received any Paging IO). So when i use
>> the same FO to perform the cacheIO, then application hangs indefinitely.
>> >>
>> >> Any idea which rule i am breaking?
>> >>
>> >> Also checking FO_CACHE_SUPPORTED flag for memory map is enough or i
>> will have to track it. As i have only seen this flag set when file is
>> memory mapped, not for regular cached FO.
>> >>
>> >> thanks in advance.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>