Hi All,
I am finding something that I did not expect in my IFS (not a filter). I am
receiving various IRPs at elevated IRQLs that are marked as asynchronous
(according to IoIsOperationSynchronous).
I thought that all IO at elevated IRQLs was supposed to be synchronous (IE,
can’t wait). Is this a bad assumption on my part?
Thanks,
Don
Don,
Why would you believe that IRPs at elevated IRQL be synchronous? Both
paging read and write operations (which occur at IRQL_APC level in XP
and older) can be performed asynchronously.
Regards,
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 Don
Sent: Thursday, May 13, 2004 8:44 AM
To: ntfsd redirect
Subject: [ntfsd] IoIsOperationSynchronous and IRQL
Hi All,
I am finding something that I did not expect in my IFS (not a filter). I
am
receiving various IRPs at elevated IRQLs that are marked as asynchronous
(according to IoIsOperationSynchronous).
I thought that all IO at elevated IRQLs was supposed to be synchronous
(IE,
can’t wait). Is this a bad assumption on my part?
Thanks,
Don
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
Tony,
You are obviously right, of course that happens. My question was very poorly
phrased. Let me try again.
It is my understanding that when an operation is synchronous, an IFS is
allowed to block if necessary. However, if an operation is asynchronous, the
IFS is not allowed to block. If the IFS might block, it must return
StatusPending and then defer the IRP to a worker thread.
However, this leads me to the question of what to do if you are called at
elevated IRQLs. Suppose I am called for a synchronous operation at an
elevated IRQL. Since the call is synchronous, I am not supposd to return
StatusPending. However, I need to perform operations that cannot take place
at a raised IRQL. In this situation, is it OK to return StatusPending and
post to a worker thread, even though the operation is supposedly
synchronous?
Thanks,
Don
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Don,
Why would you believe that IRPs at elevated IRQL be synchronous? Both
paging read and write operations (which occur at IRQL_APC level in XP
and older) can be performed asynchronously.
Regards,
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 Don
Sent: Thursday, May 13, 2004 8:44 AM
To: ntfsd redirect
Subject: [ntfsd] IoIsOperationSynchronous and IRQL
Hi All,
I am finding something that I did not expect in my IFS (not a filter). I
am
receiving various IRPs at elevated IRQLs that are marked as asynchronous
(according to IoIsOperationSynchronous).
I thought that all IO at elevated IRQLs was supposed to be synchronous
(IE,
can’t wait). Is this a bad assumption on my part?
Thanks,
Don
—
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
Don,
Thanks for the clarification.
First, keep in mind that the original design (in the long lost history
of Windows NT) for I/O was entirely asynchronous - drivers were always
allowed to return STATUS_PENDING. Subsequent additions to support
synchronous I/O have never changed this original and fundamental
precept. I’ve run into this periodically over the years and have to
repeat this lesson: a driver is allowed to return STATUS_PENDING to any
operation. There are a few odd cases where the I/O Manager doesn’t
really care (IRP_MJ_SHUTDOWN always comes to mind) but it always handles
a STATUS_PENDING return.
So the basic fallacy in your thinking is “I am not supposed to return
STATUS_PENDING for a synchronous operation.” Indicating that an I/O
operation is synchronous is merely a hint to your driver that there’s no
benefit *to the caller* from you posting the request. But if you have
your own reasons to post it, by all means, do so. The I/O Manager will
do the right thing in any case.
Another point that occurred to me when I first read your note: the term
“elevated IRQL” could mean APC_LEVEL. You are certainly allowed to
block at IRQL APC_LEVEL. You should *not* be receiving calls at
DISPATCH_LEVEL or above, however, so if you are that’s a different
matter.
There are a number of operations that cannot be performed at APC_LEVEL -
network redirectors must routinely deal with this issue, because many
TDI operations require PASSIVE_LEVEL.
For example, with a network redirector, I might post the actual work to
a worker thread and have the original thread block (at APC_LEVEL).
There is some fancy footwork, since the worker thread is acting under
the locks of the original thread, but this technique does work…
I hope this helps.
Regards,
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 Don
Sent: Thursday, May 13, 2004 9:22 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IoIsOperationSynchronous and IRQL
Tony,
You are obviously right, of course that happens. My question was very
poorly
phrased. Let me try again.
It is my understanding that when an operation is synchronous, an IFS is
allowed to block if necessary. However, if an operation is asynchronous,
the
IFS is not allowed to block. If the IFS might block, it must return
StatusPending and then defer the IRP to a worker thread.
However, this leads me to the question of what to do if you are called
at
elevated IRQLs. Suppose I am called for a synchronous operation at an
elevated IRQL. Since the call is synchronous, I am not supposd to return
StatusPending. However, I need to perform operations that cannot take
place
at a raised IRQL. In this situation, is it OK to return StatusPending
and
post to a worker thread, even though the operation is supposedly
synchronous?
Thanks,
Don
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Don,
Why would you believe that IRPs at elevated IRQL be synchronous? Both
paging read and write operations (which occur at IRQL_APC level in XP
and older) can be performed asynchronously.
Regards,
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 Don
Sent: Thursday, May 13, 2004 8:44 AM
To: ntfsd redirect
Subject: [ntfsd] IoIsOperationSynchronous and IRQL
Hi All,
I am finding something that I did not expect in my IFS (not a filter). I
am
receiving various IRPs at elevated IRQLs that are marked as asynchronous
(according to IoIsOperationSynchronous).
I thought that all IO at elevated IRQLs was supposed to be synchronous
(IE,
can’t wait). Is this a bad assumption on my part?
Thanks,
Don
—
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
—
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
Tony,
Thanks, that answers my question perfectly.
Don
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Don,
Thanks for the clarification.
First, keep in mind that the original design (in the long lost history
of Windows NT) for I/O was entirely asynchronous - drivers were always
allowed to return STATUS_PENDING. Subsequent additions to support
synchronous I/O have never changed this original and fundamental
precept. I’ve run into this periodically over the years and have to
repeat this lesson: a driver is allowed to return STATUS_PENDING to any
operation. There are a few odd cases where the I/O Manager doesn’t
really care (IRP_MJ_SHUTDOWN always comes to mind) but it always handles
a STATUS_PENDING return.
So the basic fallacy in your thinking is “I am not supposed to return
STATUS_PENDING for a synchronous operation.” Indicating that an I/O
operation is synchronous is merely a hint to your driver that there’s no
benefit to the caller from you posting the request. But if you have
your own reasons to post it, by all means, do so. The I/O Manager will
do the right thing in any case.
Another point that occurred to me when I first read your note: the term
“elevated IRQL” could mean APC_LEVEL. You are certainly allowed to
block at IRQL APC_LEVEL. You should not be receiving calls at
DISPATCH_LEVEL or above, however, so if you are that’s a different
matter.
There are a number of operations that cannot be performed at APC_LEVEL -
network redirectors must routinely deal with this issue, because many
TDI operations require PASSIVE_LEVEL.
For example, with a network redirector, I might post the actual work to
a worker thread and have the original thread block (at APC_LEVEL).
There is some fancy footwork, since the worker thread is acting under
the locks of the original thread, but this technique does work…
I hope this helps.
Regards,
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 Don
Sent: Thursday, May 13, 2004 9:22 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IoIsOperationSynchronous and IRQL
Tony,
You are obviously right, of course that happens. My question was very
poorly
phrased. Let me try again.
It is my understanding that when an operation is synchronous, an IFS is
allowed to block if necessary. However, if an operation is asynchronous,
the
IFS is not allowed to block. If the IFS might block, it must return
StatusPending and then defer the IRP to a worker thread.
However, this leads me to the question of what to do if you are called
at
elevated IRQLs. Suppose I am called for a synchronous operation at an
elevated IRQL. Since the call is synchronous, I am not supposd to return
StatusPending. However, I need to perform operations that cannot take
place
at a raised IRQL. In this situation, is it OK to return StatusPending
and
post to a worker thread, even though the operation is supposedly
synchronous?
Thanks,
Don
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Don,
Why would you believe that IRPs at elevated IRQL be synchronous? Both
paging read and write operations (which occur at IRQL_APC level in XP
and older) can be performed asynchronously.
Regards,
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 Don
Sent: Thursday, May 13, 2004 8:44 AM
To: ntfsd redirect
Subject: [ntfsd] IoIsOperationSynchronous and IRQL
Hi All,
I am finding something that I did not expect in my IFS (not a filter). I
am
receiving various IRPs at elevated IRQLs that are marked as asynchronous
(according to IoIsOperationSynchronous).
I thought that all IO at elevated IRQLs was supposed to be synchronous
(IE,
can’t wait). Is this a bad assumption on my part?
Thanks,
Don
—
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
—
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
> repeat this lesson: a driver is allowed to return STATUS_PENDING to any
operation. There are a few odd cases where the I/O Manager doesn’t
really care (IRP_MJ_SHUTDOWN always comes to mind) but it always handles
a STATUS_PENDING return.
What about CLOSE?
network redirectors must routinely deal with this issue, because many
TDI operations require PASSIVE_LEVEL.
Connection establishment only.
Data transport can be done on DISPATCH_LEVEL - this is how iSCSI and similar
things work.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Actually, even for IRP_MJ_CLOSE and IRP_MJ_SHUTDOWN the I/O Manager will
do a block and wait if it gets back STATUS_PENDING.
The error with this is generally not in the I/O Manager, it is in other
drivers that try to take on the I/O Manager’s role, but assume that
because they set the IRP_SYNCHRONOUS_API bit the caller must treat there
request as if it were synchronous.
Regards,
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 Maxim S. Shatskih
Sent: Thursday, May 13, 2004 12:39 PM
To: ntfsd redirect
Subject: Re: [ntfsd] IoIsOperationSynchronous and IRQL
repeat this lesson: a driver is allowed to return STATUS_PENDING to
any
operation. There are a few odd cases where the I/O Manager doesn’t
really care (IRP_MJ_SHUTDOWN always comes to mind) but it always
handles
a STATUS_PENDING return.
What about CLOSE?
network redirectors must routinely deal with this issue, because many
TDI operations require PASSIVE_LEVEL.
Connection establishment only.
Data transport can be done on DISPATCH_LEVEL - this is how iSCSI and
similar
things work.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
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