Re: paging i/o and ValidDataLength/FileSize/AllocationSize

NTFSD
1

Hi all,

I am getting a a deadlock while saving a file in Microsoft Word 2003
SP2 to my file system. I am running on Windows XP SP2, checked build.

According to this thread, paging io writes from the MPW are allowed to
extend VDL.

In this case (see thread at end of this email), as I understand, Word
is setting the end of the file (in the debugger, stack frame 13 is
class FileEndOfFileInformation), which is beyond the current FileSize.
My driver extends FileSize and calls CcSetFileSizes().

This causes a flush in Mm, which eventually shows up as an MPW paging
io write in my driver again. I notice this is a write beyond VDL, so
I extend VDL and call CcSetFileSizes() again. This causes another
flush inside Mm, which blocks on an event I assume.

Who is suppose to signal this event? What am I doing wrong? Thanks.

Here is the Word thread that is stuck:

0 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
1 nt!KiSwapThread+0x46 (FPO: [0,0,0])
2 nt!KeWaitForSingleObject+0x22e (FPO: [Non-Fpo])
3 nt!MiFlushSectionInternal+0x1dd (FPO: [Non-Fpo])
4 nt!MmFlushSection+0x350 (FPO: [Non-Fpo])
5 nt!CcSetFileSizes+0x2dc (FPO: [Non-Fpo])
6 pifsk!PifsDispatchWrite+0x726 (FPO: [Non-Fpo]) (CONV: stdcall)
7 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
8 nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
9 nt!IoSynchronousPageWrite+0xaf (FPO: [Non-Fpo])
10 nt!MiFlushSectionInternal+0x684 (FPO: [Non-Fpo])
11 nt!MmFlushSection+0x350 (FPO: [Non-Fpo])
12 nt!CcSetFileSizes+0x2dc (FPO: [Non-Fpo])
13 pifsk!PifsDispatchSetInformation+0x6e3 (FPO: [Non-Fpo]) (CONV: stdcall)
14 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
15 nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
16 nt!NtSetInformationFile+0x5e7 (FPO: [Non-Fpo])
17 nt!KiFastCallEntry+0x158 (FPO: [0,3] TrapFrame @ f3984d64)
18 ntdll!KiFastSystemCallRet (FPO: [0,0,0])

(pifsk is my FSD)

=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you’re done.]

2

Don’t call CcSetFileSizes when extending VDL. From the documentation:

"File systems must call CcSetFileSizes to update the cache manager data
structures whenever one of the following changes is made to a cached
file:

  • Its allocation size is increased.
  • Its valid data length is decreased.
  • Its file size is increased or decreased."

You were INCREASING VDL so you don’t need to do that in any case.
Further, since paging I/O will never increase allocation size OR file
size (no extending writes) and it will never decrease VDL or file size
(it’s *paging I/O*) you shouldn’t be calling CcSetFileSizes in your
paging I/O path.

I hope this makes sense.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roger Tawa
Sent: Wednesday, March 01, 2006 7:02 PM
To: ntfsd redirect
Subject: Re: [ntfsd] paging i/o and
ValidDataLength/FileSize/AllocationSize

Hi all,

I am getting a a deadlock while saving a file in Microsoft Word 2003
SP2 to my file system. I am running on Windows XP SP2, checked build.

According to this thread, paging io writes from the MPW are allowed to
extend VDL.

In this case (see thread at end of this email), as I understand, Word
is setting the end of the file (in the debugger, stack frame 13 is
class FileEndOfFileInformation), which is beyond the current FileSize.
My driver extends FileSize and calls CcSetFileSizes().

This causes a flush in Mm, which eventually shows up as an MPW paging
io write in my driver again. I notice this is a write beyond VDL, so
I extend VDL and call CcSetFileSizes() again. This causes another
flush inside Mm, which blocks on an event I assume.

Who is suppose to signal this event? What am I doing wrong? Thanks.

Here is the Word thread that is stuck:

0 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4])
1 nt!KiSwapThread+0x46 (FPO: [0,0,0])
2 nt!KeWaitForSingleObject+0x22e (FPO: [Non-Fpo])
3 nt!MiFlushSectionInternal+0x1dd (FPO: [Non-Fpo])
4 nt!MmFlushSection+0x350 (FPO: [Non-Fpo])
5 nt!CcSetFileSizes+0x2dc (FPO: [Non-Fpo])
6 pifsk!PifsDispatchWrite+0x726 (FPO: [Non-Fpo]) (CONV: stdcall)
7 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
8 nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
9 nt!IoSynchronousPageWrite+0xaf (FPO: [Non-Fpo])
10 nt!MiFlushSectionInternal+0x684 (FPO: [Non-Fpo])
11 nt!MmFlushSection+0x350 (FPO: [Non-Fpo])
12 nt!CcSetFileSizes+0x2dc (FPO: [Non-Fpo])
13 pifsk!PifsDispatchSetInformation+0x6e3 (FPO: [Non-Fpo]) (CONV:
stdcall)
14 nt!IopfCallDriver+0x51 (FPO: [0,0,0])
15 nt!IovCallDriver+0xa0 (FPO: [Non-Fpo])
16 nt!NtSetInformationFile+0x5e7 (FPO: [Non-Fpo])
17 nt!KiFastCallEntry+0x158 (FPO: [0,3] TrapFrame @ f3984d64)
18 ntdll!KiFastSystemCallRet (FPO: [0,0,0])

(pifsk is my FSD)

=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you’re done.]

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Thanks Tony, I missed that (blush).

I also found this in FASTFAT, write.c, a second reason not to call
CcSetFileSizes() in this scenario:

// Rule 2: Only the top level requestor may extend Valid
// Data Length. This may be paging IO, as when a
// a user maps a file, but will never be as a result
// of cache lazy writer writes since they are not the
// top level request.

So if I understand correctly, this mean that if I get an MPW paging io
write that is not the top level IRP, that I should not extend VDL.
That is, I should not write to my file beyond VDL. Yes/no?

Thanks.

=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you’re done.]