sync paging io

NTFSD
1

Hi all,

Why does a call to CcCopyRead(), where the Wait argument is specified as
FALSE, cause a recursive *sync* paging io READ? I would have thought an
async paging io READ would have been triggered. Its not causing me any
problems (at least I don’t think so), I’m curious if I may be mishandling
IRP completion. But it does seem to imply that CcCopyRead() will wait even
when what the wait argument is false, if the underlying FSD truly implements
sync paging io in a synchronous way.

Below is an excerpt from the traces of my FSD. The first READ IRP
(8437cee8) is an async, cached, non-MDL READ from a user mode app (apache).
This calls CcCopyRead(), which causes the second READ IRP (86a1ef48) to be
called recursively. This is a sync paging io READ.

In my FSD, the paging io READ is sent to an user-mode service, so it gets
queued up in the driver while waiting for it to be processed. I am using
CSQs, so inserting the IRP into the queue implicitly calls
IoMarkIrpPending(). Because this READ IRP is sync, I do a
KeWaitForSingleObject() to wait for the IRP to complete before returning
from my READ dispatch routine. However, I still return STATUS_PENDING,
because the rules of IRP handling say that if I call IoMarkIrpPending(), I
must return STATUS_PENDING, even if the IRP has been completed in the
meantime.

Because I return STATUS_PENDING from the paging io READ to CcCopyRead(), and
because the Wait argument is FALSE, I suspect this causes CcCopyRead() to
return FALSE, although it seems unnecessary. Because CcCopyRead() returns
FALSE to the original READ from apache, my FSD interprets this as meaning
“CcCopyRead() could not do the read because it would need to block”, and so
it posts the READ IRP to a worker thread.

The worker thread then executes the original read again, but this time it is
satisfied immediately since Cc has the data. The worker thread completes
the original READ IRP.

I am doing anything incorrectly in the handling of the paging io read?
Thanks.

PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
Thread=84380020
PIFSK:8437cee8 Flags=00000000
PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) Offset=0 Length=3031
PIFSK:8437cee8 StackFlags=00000000
PIFSK:8437cee8 FO=84e2d2c8 Flags=00040020 Bits= ReadAccess SharedRead
SharedWrite SharedDelete
PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054

PIFSK:READ 86a1ef48 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
Thread=84380020
PIFSK:86a1ef48 Flags=40000043 NOCACHE PAGING_IO SYNCHRONOUS_PAGING_IO
PIFSK:86a1ef48 Minor=00(IRP_MN_NORMAL) PAGING SYNC Offset=0 Length=4096
PIFSK:86a1ef48 StackFlags=00000000
PIFSK:86a1ef48 FO=84e2d2c8 Flags=00040060 CACHE_SUPPORTED Bits=
ReadAccess SharedRead SharedWrite SharedDelete
PIFSK:86a1ef48 FCB=8572baf0 Flags=00000050 Flags2=00000002
ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
PIFSK:86a1ef48 Alloc=360448 File=360054 VDL=360054

PIFSK:READ 86a1ef48 COMPLETED Status=00000000(STATUS_SUCCESS)
Info=00001000(4096) Thread=84482900

PIFSK:8437cee8 Queuing work item 85b467d8

PIFSK:Work item 85b467d8 started
PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [System]
Thread=85e483c8
PIFSK:8437cee8 Flags=00000004 SYNCHRONOUS_API
PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) SYNC Offset=0 Length=3031
PIFSK:8437cee8 StackFlags=00000000
PIFSK:8437cee8 FO=84e2d2c8 Flags=000c0060 CACHE_SUPPORTED Bits=
ReadAccess SharedRead SharedWrite SharedDelete
PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054

PIFSK:READ 8437cee8 COMPLETED Status=00000000(STATUS_SUCCESS)
Info=00000bd7(3031) Thread=85e483c8
PIFSK:Work item 85b467d8 ended

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

2

Paging I/O read is always synchronous because the given thread cannot
continue until the page is present. The TRUE/FALSE parameter has to do
with locking state (FALSE = “do not wait for the lock”) and not with
page fault activity.

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roger Tawa
Sent: Friday, August 11, 2006 12:08 PM
To: ntfsd redirect
Subject: [ntfsd] sync paging io

Hi all,

Why does a call to CcCopyRead(), where the Wait argument is specified as
FALSE, cause a recursive *sync* paging io READ? I would have thought an
async paging io READ would have been triggered. Its not causing me any
problems (at least I don’t think so), I’m curious if I may be
mishandling
IRP completion. But it does seem to imply that CcCopyRead() will wait
even
when what the wait argument is false, if the underlying FSD truly
implements
sync paging io in a synchronous way.

Below is an excerpt from the traces of my FSD. The first READ IRP
(8437cee8) is an async, cached, non-MDL READ from a user mode app
(apache).
This calls CcCopyRead(), which causes the second READ IRP (86a1ef48) to
be
called recursively. This is a sync paging io READ.

In my FSD, the paging io READ is sent to an user-mode service, so it
gets
queued up in the driver while waiting for it to be processed. I am
using
CSQs, so inserting the IRP into the queue implicitly calls
IoMarkIrpPending(). Because this READ IRP is sync, I do a
KeWaitForSingleObject() to wait for the IRP to complete before returning
from my READ dispatch routine. However, I still return STATUS_PENDING,
because the rules of IRP handling say that if I call IoMarkIrpPending(),
I
must return STATUS_PENDING, even if the IRP has been completed in the
meantime.

Because I return STATUS_PENDING from the paging io READ to CcCopyRead(),
and
because the Wait argument is FALSE, I suspect this causes CcCopyRead()
to
return FALSE, although it seems unnecessary. Because CcCopyRead()
returns
FALSE to the original READ from apache, my FSD interprets this as
meaning
“CcCopyRead() could not do the read because it would need to block”, and
so
it posts the READ IRP to a worker thread.

The worker thread then executes the original read again, but this time
it is
satisfied immediately since Cc has the data. The worker thread
completes
the original READ IRP.

I am doing anything incorrectly in the handling of the paging io read?
Thanks.

PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
Thread=84380020
PIFSK:8437cee8 Flags=00000000
PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) Offset=0 Length=3031
PIFSK:8437cee8 StackFlags=00000000
PIFSK:8437cee8 FO=84e2d2c8 Flags=00040020 Bits= ReadAccess SharedRead
SharedWrite SharedDelete
PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054

PIFSK:READ 86a1ef48 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
Thread=84380020
PIFSK:86a1ef48 Flags=40000043 NOCACHE PAGING_IO SYNCHRONOUS_PAGING_IO

PIFSK:86a1ef48 Minor=00(IRP_MN_NORMAL) PAGING SYNC Offset=0 Length=4096
PIFSK:86a1ef48 StackFlags=00000000
PIFSK:86a1ef48 FO=84e2d2c8 Flags=00040060 CACHE_SUPPORTED Bits=
ReadAccess SharedRead SharedWrite SharedDelete
PIFSK:86a1ef48 FCB=8572baf0 Flags=00000050 Flags2=00000002
ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
PIFSK:86a1ef48 Alloc=360448 File=360054 VDL=360054

PIFSK:READ 86a1ef48 COMPLETED Status=00000000(STATUS_SUCCESS)
Info=00001000(4096) Thread=84482900

PIFSK:8437cee8 Queuing work item 85b467d8

PIFSK:Work item 85b467d8 started
PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [System]
Thread=85e483c8
PIFSK:8437cee8 Flags=00000004 SYNCHRONOUS_API
PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) SYNC Offset=0 Length=3031
PIFSK:8437cee8 StackFlags=00000000
PIFSK:8437cee8 FO=84e2d2c8 Flags=000c0060 CACHE_SUPPORTED Bits=
ReadAccess SharedRead SharedWrite SharedDelete
PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054

PIFSK:READ 8437cee8 COMPLETED Status=00000000(STATUS_SUCCESS)
Info=00000bd7(3031) Thread=85e483c8
PIFSK:Work item 85b467d8 ended

=================================================
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: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Hi,
The page faults are generated when the CcCopyRead reads the data from the
memory mapping the file. To avoid page faults the pages must be locked, it
seems the CcCopyRead doesn’t check this when copies data. The FALSE is
returned if the needed portion of the file is not mapped and cannot be
mapped w/o blocking.

–
Slava Imameyev, xxxxx@hotmail.com

“Roger Tawa” wrote in message news:xxxxx@ntfsd…
> Hi all,
>
> Why does a call to CcCopyRead(), where the Wait argument is specified as
> FALSE, cause a recursive sync paging io READ? I would have thought an
> async paging io READ would have been triggered. Its not causing me any
> problems (at least I don’t think so), I’m curious if I may be mishandling
> IRP completion. But it does seem to imply that CcCopyRead() will wait
> even
> when what the wait argument is false, if the underlying FSD truly
> implements
> sync paging io in a synchronous way.
>
> Below is an excerpt from the traces of my FSD. The first READ IRP
> (8437cee8) is an async, cached, non-MDL READ from a user mode app
> (apache).
> This calls CcCopyRead(), which causes the second READ IRP (86a1ef48) to be
> called recursively. This is a sync paging io READ.
>
> In my FSD, the paging io READ is sent to an user-mode service, so it gets
> queued up in the driver while waiting for it to be processed. I am using
> CSQs, so inserting the IRP into the queue implicitly calls
> IoMarkIrpPending(). Because this READ IRP is sync, I do a
> KeWaitForSingleObject() to wait for the IRP to complete before returning
> from my READ dispatch routine. However, I still return STATUS_PENDING,
> because the rules of IRP handling say that if I call IoMarkIrpPending(), I
> must return STATUS_PENDING, even if the IRP has been completed in the
> meantime.
>
> Because I return STATUS_PENDING from the paging io READ to CcCopyRead(),
> and
> because the Wait argument is FALSE, I suspect this causes CcCopyRead() to
> return FALSE, although it seems unnecessary. Because CcCopyRead() returns
> FALSE to the original READ from apache, my FSD interprets this as meaning
> “CcCopyRead() could not do the read because it would need to block”, and
> so
> it posts the READ IRP to a worker thread.
>
> The worker thread then executes the original read again, but this time it
> is
> satisfied immediately since Cc has the data. The worker thread completes
> the original READ IRP.
>
> I am doing anything incorrectly in the handling of the paging io read?
> Thanks.
>
>
> PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
> Thread=84380020
> PIFSK:8437cee8 Flags=00000000
> PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) Offset=0 Length=3031
> PIFSK:8437cee8 StackFlags=00000000
> PIFSK:8437cee8 FO=84e2d2c8 Flags=00040020 Bits= ReadAccess SharedRead
> SharedWrite SharedDelete
> PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
> ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
> PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054
>
> PIFSK:READ 86a1ef48 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
> Thread=84380020
> PIFSK:86a1ef48 Flags=40000043 NOCACHE PAGING_IO SYNCHRONOUS_PAGING_IO
> PIFSK:86a1ef48 Minor=00(IRP_MN_NORMAL) PAGING SYNC Offset=0 Length=4096
> PIFSK:86a1ef48 StackFlags=00000000
> PIFSK:86a1ef48 FO=84e2d2c8 Flags=00040060 CACHE_SUPPORTED Bits=
> ReadAccess SharedRead SharedWrite SharedDelete
> PIFSK:86a1ef48 FCB=8572baf0 Flags=00000050 Flags2=00000002
> ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
> PIFSK:86a1ef48 Alloc=360448 File=360054 VDL=360054
>
> PIFSK:READ 86a1ef48 COMPLETED Status=00000000(STATUS_SUCCESS)
> Info=00001000(4096) Thread=84482900
>
> PIFSK:8437cee8 Queuing work item 85b467d8
>
> PIFSK:Work item 85b467d8 started
> PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [System]
> Thread=85e483c8
> PIFSK:8437cee8 Flags=00000004 SYNCHRONOUS_API
> PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) SYNC Offset=0 Length=3031
> PIFSK:8437cee8 StackFlags=00000000
> PIFSK:8437cee8 FO=84e2d2c8 Flags=000c0060 CACHE_SUPPORTED Bits=
> ReadAccess SharedRead SharedWrite SharedDelete
> PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
> ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
> PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054
>
> PIFSK:READ 8437cee8 COMPLETED Status=00000000(STATUS_SUCCESS)
> Info=00000bd7(3031) Thread=85e483c8
> PIFSK:Work item 85b467d8 ended
>
> =================================================
> Roger Tawa
> http://tawacentral.net/
> [One thing about paradigms: shift happens.]
> [When you stop, you’re done.]
>
>
>
>

4

Thanks Tony, Slava.

Does this means my IRP handling is correct?

I’m still not clear on why CcCopyRead() is returning FALSE. In this
particular case, at the time I call CcCopyRead(), I already have the
main FCB resource acquired shared. My FCB uses the flag
ACQUIRE_MAIN_RSRC_SH, and the PagingIoResource field is null. The
callbacks I install at CcInitializeCacheMap() time acquire the main
FCB resource shared.

At the time of this request, there were no other IRPs pending or any
other activity going on in my FSD. I don’t have any of the fastio
dispatch entry points defined, except for FastIoCheckIfPossible,
FastIoRead, and FastIoWrite. While the latter two are set to the
standard FsRtl routines meant for these entry points, the first is
hardcoded for the moment to always return FALSE, so effectively fastio
is disabled.

Is it a Cc lock or VMM lock then that could not be acquired?

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

5

Roger,

It doesn’t matter WHAT would have caused the blocking condition - you
said “don’t block for this” and the cache manager said “ok, sorry but
this would block.” The only confusing point here is that “don’t block
for this” does NOT include blocking for page faults (which could easily
be the most expensive.)

This doesn’t have anything to do with Fast I/O - by the time you’re
calling CcCopyRead you are below the level at which Fast I/O would get
invoked.

I usually use this to decide if I want to post it or not (eventually,
someone has to WAIT for the I/O to finish, but it doesn’t have to be the
original thread.)

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roger Tawa
Sent: Friday, August 11, 2006 2:16 PM
To: ntfsd redirect
Subject: Re: [ntfsd] sync paging io

Thanks Tony, Slava.

Does this means my IRP handling is correct?

I’m still not clear on why CcCopyRead() is returning FALSE. In this
particular case, at the time I call CcCopyRead(), I already have the
main FCB resource acquired shared. My FCB uses the flag
ACQUIRE_MAIN_RSRC_SH, and the PagingIoResource field is null. The
callbacks I install at CcInitializeCacheMap() time acquire the main
FCB resource shared.

At the time of this request, there were no other IRPs pending or any
other activity going on in my FSD. I don’t have any of the fastio
dispatch entry points defined, except for FastIoCheckIfPossible,
FastIoRead, and FastIoWrite. While the latter two are set to the
standard FsRtl routines meant for these entry points, the first is
hardcoded for the moment to always return FALSE, so effectively fastio
is disabled.

Is it a Cc lock or VMM lock then that could not be acquired?

=================================================
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: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

>at the time I call CcCopyRead(), I already have the

main FCB resource acquired shared.

Correct. You do not have to acquire any other locks except your FSD’s locks.

My FCB uses the flag
ACQUIRE_MAIN_RSRC_SH, and the PagingIoResource >field is null. The
callbacks I install at CcInitializeCacheMap() time acquire the >main
FCB resource shared.

These callbacks are used only by the Cache Manger’s lazy writer and read
ahead threads, because the FSD’s resources must be acquired before the Cache
Manager and Memory Manager’s resources. The CcCopyRead does not use these
callbacks.

You observe the request initiated by the Page Fault Handler, I think you can
see its functions in the call stack above your FSD’s dispatch routine.
CcCopyRead( Wait=FALSE ) read the data from the cache if the entire
requested region is mapped to the system space( but the pages may be
pageout!), this read may generate page faults and calls the Page Fault
Handler to perform pagein. Also, notice that the CcCopyRead code is in the
PAGE segment of the kernel, this is not your case, but yet another way to
generate page faults.

–
Slava Imameyev, xxxxx@hotmail.com

“Roger Tawa” wrote in message news:xxxxx@ntfsd…
> Hi all,
>
> Why does a call to CcCopyRead(), where the Wait argument is specified as
> FALSE, cause a recursive sync paging io READ? I would have thought an
> async paging io READ would have been triggered. Its not causing me any
> problems (at least I don’t think so), I’m curious if I may be mishandling
> IRP completion. But it does seem to imply that CcCopyRead() will wait
> even
> when what the wait argument is false, if the underlying FSD truly
> implements
> sync paging io in a synchronous way.
>
> Below is an excerpt from the traces of my FSD. The first READ IRP
> (8437cee8) is an async, cached, non-MDL READ from a user mode app
> (apache).
> This calls CcCopyRead(), which causes the second READ IRP (86a1ef48) to be
> called recursively. This is a sync paging io READ.
>
> In my FSD, the paging io READ is sent to an user-mode service, so it gets
> queued up in the driver while waiting for it to be processed. I am using
> CSQs, so inserting the IRP into the queue implicitly calls
> IoMarkIrpPending(). Because this READ IRP is sync, I do a
> KeWaitForSingleObject() to wait for the IRP to complete before returning
> from my READ dispatch routine. However, I still return STATUS_PENDING,
> because the rules of IRP handling say that if I call IoMarkIrpPending(), I
> must return STATUS_PENDING, even if the IRP has been completed in the
> meantime.
>
> Because I return STATUS_PENDING from the paging io READ to CcCopyRead(),
> and
> because the Wait argument is FALSE, I suspect this causes CcCopyRead() to
> return FALSE, although it seems unnecessary. Because CcCopyRead() returns
> FALSE to the original READ from apache, my FSD interprets this as meaning
> “CcCopyRead() could not do the read because it would need to block”, and
> so
> it posts the READ IRP to a worker thread.
>
> The worker thread then executes the original read again, but this time it
> is
> satisfied immediately since Cc has the data. The worker thread completes
> the original READ IRP.
>
> I am doing anything incorrectly in the handling of the paging io read?
> Thanks.
>
>
> PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
> Thread=84380020
> PIFSK:8437cee8 Flags=00000000
> PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) Offset=0 Length=3031
> PIFSK:8437cee8 StackFlags=00000000
> PIFSK:8437cee8 FO=84e2d2c8 Flags=00040020 Bits= ReadAccess SharedRead
> SharedWrite SharedDelete
> PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
> ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
> PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054
>
> PIFSK:READ 86a1ef48 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [Apache.exe]
> Thread=84380020
> PIFSK:86a1ef48 Flags=40000043 NOCACHE PAGING_IO SYNCHRONOUS_PAGING_IO
> PIFSK:86a1ef48 Minor=00(IRP_MN_NORMAL) PAGING SYNC Offset=0 Length=4096
> PIFSK:86a1ef48 StackFlags=00000000
> PIFSK:86a1ef48 FO=84e2d2c8 Flags=00040060 CACHE_SUPPORTED Bits=
> ReadAccess SharedRead SharedWrite SharedDelete
> PIFSK:86a1ef48 FCB=8572baf0 Flags=00000050 Flags2=00000002
> ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
> PIFSK:86a1ef48 Alloc=360448 File=360054 VDL=360054
>
> PIFSK:READ 86a1ef48 COMPLETED Status=00000000(STATUS_SUCCESS)
> Info=00001000(4096) Thread=84482900
>
> PIFSK:8437cee8 Queuing work item 85b467d8
>
> PIFSK:Work item 85b467d8 started
> PIFSK:READ 8437cee8 DO=84482d70 “\hi.bmp” FO=84e2d2c8 [System]
> Thread=85e483c8
> PIFSK:8437cee8 Flags=00000004 SYNCHRONOUS_API
> PIFSK:8437cee8 Minor=00(IRP_MN_NORMAL) SYNC Offset=0 Length=3031
> PIFSK:8437cee8 StackFlags=00000000
> PIFSK:8437cee8 FO=84e2d2c8 Flags=000c0060 CACHE_SUPPORTED Bits=
> ReadAccess SharedRead SharedWrite SharedDelete
> PIFSK:8437cee8 FCB=8572baf0 Flags=00000050 Flags2=00000002
> ACQUIRE_MAIN_RSRC_SH ADVANCED_HEADERSUPPORTS_FILTER_CONTEXTS
> PIFSK:8437cee8 Alloc=360448 File=360054 VDL=360054
>
> PIFSK:READ 8437cee8 COMPLETED Status=00000000(STATUS_SUCCESS)
> Info=00000bd7(3031) Thread=85e483c8
> PIFSK:Work item 85b467d8 ended
>
> =================================================
> Roger Tawa
> http://tawacentral.net/
> [One thing about paradigms: shift happens.]
> [When you stop, you’re done.]
>
>
>
>

7

> Why does a call to CcCopyRead(), where the Wait argument is specified as

FALSE, cause a recursive *sync* paging io READ? I would have thought an
async paging io READ would have been triggered. Its not causing me any

IIRC all paging reads are (normally, too-smart filters aside) generated in
IoPageRead, and they are always sync.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

8

> Is it a Cc lock or VMM lock then that could not be acquired?

I think yes.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com