STATUS_PENDING for IRP_MJ_CREATE

NTFSD
1

Hai All,

Can a file system filter driver return STATUS_PENDING for IRP_MJ_CREATE
and complete the IRP in another thread.

My file system filter driver wants to queue the IRP_MJ_CREATE for a
particular file and then do some work and then after finishing the work
remove the IRP from the queue and then pass to the file system driver so
that IRP will be processed normally from now.

And also does the application waits for the completion of file open
request if the file system filter driver returns STATUS_PENDING.

Any information would be helpful.

Thanx in advance,
Kedar.

2

I do not think that it is safe to change the process context of a create
call.

Since IRP_MJ_CREATE is called at passive level and the process calling
the create is going to block; create has no overlapped mode. I recommend
just doing you processing in the create path and not posting to a
thread. You gain nothing.

Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, May 23, 2002 10:57 PM
To: File Systems Developers
Subject: [ntfsd] STATUS_PENDING for IRP_MJ_CREATE

Hai All,

Can a file system filter driver return STATUS_PENDING for IRP_MJ_CREATE
and complete the IRP in another thread.

My file system filter driver wants to queue the IRP_MJ_CREATE for a
particular file and then do some work and then after finishing the work
remove the IRP from the queue and then pass to the file system driver so
that IRP will be processed normally from now.

And also does the application waits for the completion of file open
request if the file system filter driver returns STATUS_PENDING.

Any information would be helpful.

Thanx in advance,
Kedar.

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

3

Kedar,

Jamey’s point is salient (there’s generally no advantage to working in a
worker thread) although the answer to your actual question is “yes, it CAN.”
The I/O interface started out as 100% asynchronous and all of the bits added
since then have been to encourage/use more synchrony, but the whole
interface WAS asynchronous, even create. The I/O Manager will handle this.

The problem that everyone will point out is “ah, but what about the calling
context”. You lose the security information, process context, and other
essential information when you post the IRP_MJ_CREATE to a different thread,
requiring that you capture it or do other substantial processing. Given
that the caller will block-and-wait anyway, there’s no advantage.

Just as an aside, there is one case where create is (essentially)
asynchronous anyway (albeit in a complex keep-them-on-their-toes sort of
way.) If a create IRP specifies the “complete if oplocked” option, the
status code can be “oplock break in progress” which essentially means “call
back later and I’ll tell you when I’m done” which is a round-about way to
implement asynchronous create.

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
xxxxx@hotmail.com
Sent: Thursday, May 23, 2002 10:57 PM
To: File Systems Developers
Subject: [ntfsd] STATUS_PENDING for IRP_MJ_CREATE

Hai All,

Can a file system filter driver return STATUS_PENDING for IRP_MJ_CREATE
and complete the IRP in another thread.

My file system filter driver wants to queue the IRP_MJ_CREATE for a
particular file and then do some work and then after finishing the work
remove the IRP from the queue and then pass to the file system driver so
that IRP will be processed normally from now.

And also does the application waits for the completion of file open
request if the file system filter driver returns STATUS_PENDING.

Any information would be helpful.

Thanx in advance,
Kedar.

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

4

> Can a file system filter driver return STATUS_PENDING for
IRP_MJ_CREATE

and complete the IRP in another thread.

My file system filter driver wants to queue the IRP_MJ_CREATE for a

Why not do all of this synchronously in CREATE dispatch with blocking?
CREATE is synchronous anyway.

Max

5

Create IRPs sent from the I/O Manager are synchronous. NOTHING prevents
some other kernel component from sending a create operation and NOT
blocking.

It is a dangerous thing to assert that because nobody does something it
cannot be done that way. And, as I pointed out earlier, there is at least
ONE case of asynchronous create, as strange as it might be.

In fact, I find myself tempted to write an NT Insider article for a fiendish
driver that never asks for synchronous behavior at all. I mean, I could see
good reasons for asynchronous create (e.g., suppose you have a slow-open
device, like something that forces migration back in from the tape catalog)
that would benefit from asynchronous behavior. But (of course) since
“create is synchronous” has now become the rule, you have to use multiple
threads (complicating serialization and introducing a different class of
bugs) to simulate this behavior.

Remember: the original design was 100% asynchronous. Anyone who assumes
that just because they set the IRP_SYNCHRONOUS_API bit, or the
FO_SYNCHRONOUS_IO bit in the file object or EVEN the
IRP_SYNCHRONOUS_PAGING_IO bit, they are going to GET synchronous behavior is
broken. Synchronous behavior has been added for performance reasons.

A common mistake in our business is to think that the world is only as big
as we can observe at the current time. I actually admire the original NT
development team’s willingness to attempt to build a very broad and
expansive architecture. Having done this on other projects, I know how
difficult it is to do well - leave enough room for future expansion, without
making the interface so incredibly complex that nobody can use or implement
it. (Hmm. I guess I’ve heard too many people saying “what a stupid OS” this
week. Time to put the soapbox away.)

Regards,

Tony

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

Hope to see you at the next OSR file systems class October 7, 2002!

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, May 24, 2002 11:39 AM
To: File Systems Developers
Subject: [ntfsd] Re: STATUS_PENDING for IRP_MJ_CREATE

Can a file system filter driver return STATUS_PENDING for
IRP_MJ_CREATE
and complete the IRP in another thread.

My file system filter driver wants to queue the IRP_MJ_CREATE for a

Why not do all of this synchronously in CREATE dispatch with blocking?
CREATE is synchronous anyway.

Max

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

6

> The problem that everyone will point out is "ah, but what about the
calling

context". You lose the security information

No, it is in IO_SECURITY_CONTEXT pointed to by Parameters.Create.

Max

7

Agreed… Yes, you can…

Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, May 24, 2002 9:10 AM
To: File Systems Developers
Subject: [ntfsd] Re: STATUS_PENDING for IRP_MJ_CREATE

Create IRPs sent from the I/O Manager are synchronous. NOTHING prevents
some other kernel component from sending a create operation and NOT
blocking.

It is a dangerous thing to assert that because nobody does something it
cannot be done that way. And, as I pointed out earlier, there is at
least
ONE case of asynchronous create, as strange as it might be.

In fact, I find myself tempted to write an NT Insider article for a
fiendish
driver that never asks for synchronous behavior at all. I mean, I could
see
good reasons for asynchronous create (e.g., suppose you have a slow-open
device, like something that forces migration back in from the tape
catalog)
that would benefit from asynchronous behavior. But (of course) since
“create is synchronous” has now become the rule, you have to use
multiple
threads (complicating serialization and introducing a different class of
bugs) to simulate this behavior.

Remember: the original design was 100% asynchronous. Anyone who assumes
that just because they set the IRP_SYNCHRONOUS_API bit, or the
FO_SYNCHRONOUS_IO bit in the file object or EVEN the
IRP_SYNCHRONOUS_PAGING_IO bit, they are going to GET synchronous
behavior is
broken. Synchronous behavior has been added for performance reasons.

A common mistake in our business is to think that the world is only as
big
as we can observe at the current time. I actually admire the original
NT
development team’s willingness to attempt to build a very broad and
expansive architecture. Having done this on other projects, I know how
difficult it is to do well - leave enough room for future expansion,
without
making the interface so incredibly complex that nobody can use or
implement
it. (Hmm. I guess I’ve heard too many people saying “what a stupid OS”
this
week. Time to put the soapbox away.)

Regards,

Tony

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

Hope to see you at the next OSR file systems class October 7, 2002!

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, May 24, 2002 11:39 AM
To: File Systems Developers
Subject: [ntfsd] Re: STATUS_PENDING for IRP_MJ_CREATE

Can a file system filter driver return STATUS_PENDING for
IRP_MJ_CREATE
and complete the IRP in another thread.

My file system filter driver wants to queue the IRP_MJ_CREATE for a

Why not do all of this synchronously in CREATE dispatch with blocking?
CREATE is synchronous anyway.

Max

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

8

> Create IRPs sent from the I/O Manager are synchronous. NOTHING
prevents

some other kernel component from sending a create operation and NOT
blocking.

Anyway such things are severe undocumented hackery (creating an empty
file object and so on), and I think the performance considerations
connected to it can be neglected.

Also note that blocking in PnP IRP path is a usual thing.

Max

9

“Tony Mason” wrote in message news:xxxxx@ntfsd…
>
> I actually admire the original NT
> development team’s willingness to attempt to build a very broad and
> expansive architecture

Well, Cutler and crew had a lot of experience with the asynchronous model,
starting with DEC’s RSX11-M and VAX/VMS. It worked well twice, and I think
NT was an attempt to polish the model even further.

Carl Appellof

10

Greetings mortal, xxxxx@hotmail.com!
You wrote on Fri, 24 May 2002 01:56:48 -0400:

k> Can a file system filter driver return STATUS_PENDING for
k> IRP_MJ_CREATE and complete the IRP in another thread.
Yes. :wink: But it isn’t safe.

k> My file system filter driver wants to queue the IRP_MJ_CREATE for a
k> particular file and then do some work and then after finishing the
k> work remove the IRP from the queue and then pass to the file system
k> driver so that IRP will be processed normally from now.
I experimented with such processing…

k> And also does the application waits for the completion of file open
k> request if the file system filter driver returns STATUS_PENDING.
IO Manager only waits on FileObject event and doesn’t check status. :frowning: So,
if some bad filter upper you call in it’s completion something like
IoQueryInformation, ObGetObjectSecurity etc, you lose your file becase event
will signaled. And in work item you get a page fault.

So, if I want to do some additional processing (and on PASSIVE_LEVEL) in
create path I must to wait on my event, which will signaled in my
completion? What is the best safe way?

Eugene.