Necessary to pend IRP_MN_QUERY_CAPABILITIES?

IRP_MN_QUERY_CAPABILITIES is documented as being sent in an "arbitrary
thread context", and I thought the rule was never to block in an
arbitrary thread context, but the DDK toaster bus sample looks like it
does a KeWaitForSingleObject in its handler for the IRP. Did I
misunderstand the rule?

soviet_bloke
Thu Nov 16 18:57:44 CST 2006

The term "arbitrary thread context" means that some particular event
may be processed in context of any thread, i.e. context is not
pre-defined. For some certain events context is pre-defined, and for
some it is not. For example, DriverEntry() always gets called in
context of the system thread, and interrupt may get processed in
context of any thread.
The same story with IRPs - for some certain events context is
pre-defined (for example, IRP_MJ_CREATE always gets sent in context of
the thread that calls CreateFile()), and for some it is not. Therefore,
the only thing MSDN says is that IRP_MN_QUERY_CAPABILITIES may get sent
in context of any thread. It has nothing to do with waiting - the
possibility of waiting is defined by IRQL, rather than thread context


Anton Bassov


BubbaGump wrote:
> IRP_MN_QUERY_CAPABILITIES is documented as being sent in an "arbitrary
> thread context", and I thought the rule was never to block in an
> arbitrary thread context, but the DDK toaster bus sample looks like it
> does a KeWaitForSingleObject in its handler for the IRP. Did I
> misunderstand the rule?

BubbaGump
Tue Nov 21 17:09:37 CST 2006

I thought thread context was related to waiting but differently from
the way IRQL is. I thought thread context was concerned with
politeness, while IRQL was concerned with stability. Isn't waiting in
a thread context unrelated to what the driver is currently doing
impolite because it will steal that other thread's CPU time? (while
waiting at an IRQL that is too high could cause some sort of deadlock)




On 16 Nov 2006 16:57:44 -0800, soviet_bloke@hotmail.com wrote:

>The term "arbitrary thread context" means that some particular event
>may be processed in context of any thread, i.e. context is not
>pre-defined. For some certain events context is pre-defined, and for
>some it is not. For example, DriverEntry() always gets called in
>context of the system thread, and interrupt may get processed in
>context of any thread.
>The same story with IRPs - for some certain events context is
>pre-defined (for example, IRP_MJ_CREATE always gets sent in context of
>the thread that calls CreateFile()), and for some it is not. Therefore,
>the only thing MSDN says is that IRP_MN_QUERY_CAPABILITIES may get sent
>in context of any thread. It has nothing to do with waiting - the
>possibility of waiting is defined by IRQL, rather than thread context
>
>
>Anton Bassov
>
>
>BubbaGump wrote:
>> IRP_MN_QUERY_CAPABILITIES is documented as being sent in an "arbitrary
>> thread context", and I thought the rule was never to block in an
>> arbitrary thread context, but the DDK toaster bus sample looks like it
>> does a KeWaitForSingleObject in its handler for the IRP. Did I
>> misunderstand the rule?

BubbaGump
Wed Nov 22 13:13:43 CST 2006

By the way, I'm taking this conclusion partly from the "Passive in
arbitrary context?" thread from a while ago. I am curious to know
whether this is valid and how much it applies to
IRP_MN_QUERY_CAPABILITIES.




On Tue, 21 Nov 2006 18:09:41 -0500, BubbaGump <> wrote:

>I thought thread context was related to waiting but differently from
>the way IRQL is. I thought thread context was concerned with
>politeness, while IRQL was concerned with stability. Isn't waiting in
>a thread context unrelated to what the driver is currently doing
>impolite because it will steal that other thread's CPU time? (while
>waiting at an IRQL that is too high could cause some sort of deadlock)

BubbaGump
Sun Nov 26 18:42:42 CST 2006

Okay, I guess no one's going to answer. This question was actually a
little rhetorical.

I was already guessing the information returned in handling an
IRP_MN_QUERY_CAPABILITIES can usually or always be filled in by a few
assignment statements that take almost no time, which would mean there
would be no reason to pend it. Contrarily the driver model allows any
IRP to be pended, so if for example a bus driver servicing this IRP
for one of its child devices sends a similar IRP to its parent device
stack, it has to safely handle the case of getting STATUS_PENDING
back, and it's a little simpler to wait for the IRP to complete than
to use a completion routine. (Although, I would argue that if an IRP
can be pended, it can technically take an arbitrarily long time so
it'd probably be good not to wait for it.)

So, all I was really looking for was some admission that the code in
the sample was motivated by a desire for simplicity, and if that guess
was wrong then I was hoping to find out the real motivation.




On Wed, 22 Nov 2006 14:13:46 -0500, BubbaGump <> wrote:

>By the way, I'm taking this conclusion partly from the "Passive in
>arbitrary context?" thread from a while ago. I am curious to know
>whether this is valid and how much it applies to
>IRP_MN_QUERY_CAPABILITIES.
>
>
>
>
>On Tue, 21 Nov 2006 18:09:41 -0500, BubbaGump <> wrote:
>
>>I thought thread context was related to waiting but differently from
>>the way IRQL is. I thought thread context was concerned with
>>politeness, while IRQL was concerned with stability. Isn't waiting in
>>a thread context unrelated to what the driver is currently doing
>>impolite because it will steal that other thread's CPU time? (while
>>waiting at an IRQL that is too high could cause some sort of deadlock)

BubbaGump
Sun Nov 26 20:26:54 CST 2006

Yes, I know I misspoke when I implied waiting on an IRP would never
involve a completion routine. What I meant is that the completion
routine and the context passed to it would be a little simpler, maybe.
I don't know. I'm trying to guess why the sample's code is written
the way it is.




On Sun, 26 Nov 2006 19:42:44 -0500, BubbaGump <> wrote:

>back, and it's a little simpler to wait for the IRP to complete than
>to use a completion routine.