Matthew is correct in his description for #1 below. In these situations
you have to assume locks are being held.
A second reason it is not safe to pend paging IO is because you are
usually at APC IRQL. If you pend an IO at APC IRQL then the special
kernel APC that is needed to complete the IO can not be processed (your
at APC level) and the IO will again deadlock.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Thursday, January 13, 2005 5:32 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] returning status_pending from a paging io read
1)I think that the reason that it’s not “safe” is that these components
have
preacquired resources for the file, and if you try to perform these
operations in another thread before getting a hold of the resources, you
can
deadlock because it is another thread trying to grab the resources (the
worker thread) instead of the original thread context that owns the
resource.
2)I believe this is true; in fact as far as I understand the MPW will
request asynchronous behavior for writes of dirty pages, and if you
block
this thread it is a bad thing because it is trying to write out pages as
fast as possible.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Mancuso
Sent: Monday, January 10, 2005 11:55 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] returning status_pending from a paging io read
Hello,
I have spent a long time searching this list archive to attempt to
find
the answer to my question. It has been answered to varying degrees
already.
However, it seems various advice conflicts or unclear to me so I’m going
to
ask again in regards to my specific application.
My current model takes all requests that are marked with IRP_NOCACHE and
attempts to satisfy them by asking a user mode component for the data.
I store the original IRP in an internal queue and then issue a request
to my
usermode sending a message that a read needs to be satisfied.
The usermode service then queries the remote server for the data, it
sends
down a custom ioctl to my driver containing the read data, I then pull
the
original noncached IRP out of the queue, acquire the correct resources,
fill
out the data, and complete with STATUS_SUCCESS. A similar process
happens
for writes, where I send the data up to usermode asking for the data to
be
written, and will eventually complete the paging write once I’ve learned
the
status of the operation.
-
I have read that it is “not safe” to pend requests that are not top
level, specically requests by the cache manager made for the purposes of
paging IO. What does that mean, exactly? Are there conditions in which
it
is safe?
-
If it is “safe,” will the MPW/lazy writer continually write data as I
return status_pending from the original dispatch?
-
In your opinion, what would be the safest way to satisfy paging io
requests for reads and writes via a user mode service. As I see it, I
can
either use the method I’m using: return status pending, then eventually
complete in response to an ioctl from usermode. Or I can block within
the
within the original paging io request until the data comes in via an
ioctl
from usermode.
Ideally I would move all that code down to kernel mode, but it leverages
some code which I do not have the source for or the time to rewrite.
Thanks.
-Jeff
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@bitarmor.com To
unsubscribe
send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com