IoCompleteRequest() from WorkItem

zedy · March 8, 2006, 3:05pm

Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the irp
as a context and do some work in it. In the end of the workitem’s function,
I complete the IRP.

Back to the dispatch routine ? after allocating and queuing the workitem, I
return STATUS_PENDING.

Now, because I’m in PASSIVE level, there can be a context switch from my
dispatch routine to my workitem’s function, so it will run and complete the
irp, before I return STATUS_PENDING from the dispatch routine. (it means
that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I handle
it?

thanks

Gary_Little-2 · March 8, 2006, 3:28pm

You need to sync your work item at PASSIVE with other functions that can
complete or cancel the IRP. The easiest way to do that, and is cross IRQL
compatible, is to hold a spinlock any time the IRP is about to be
manipulated; e.g. acquire the spinlock before you acquire the IRP. Cancel
Safe Queues are great for this and KMDFs queuing mechanism appear to be
even better.

Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Wednesday, March 08, 2006 2:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoCompleteRequest() from WorkItem

Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the irp
as a context and do some work in it. In the end of the workitem’s
function, I complete the IRP.

Back to the dispatch routine - after allocating and queuing the workitem,
I return STATUS_PENDING .

Now, because I’m in PASSIVE level, there can be a context switch from my
dispatch routine to my workitem’s function, so it will run and complete
the irp, before I return STATUS_PENDING from the dispatch routine. (it
means that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I
handle it?

thanks

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Pankaj_Garg · March 8, 2006, 3:37pm

You first mark the IRP pending by doing IoMarkIrpPending, then queue the work item and then you can safely return STATUS_PENDING. However, if your IRP is cancellable, the logic becomes little more tricky.

–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.

“Zed y” wrote in message news:xxxxx@ntdev…
Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the irp as a context and do some work in it. In the end of the workitem’s function, I complete the IRP.

Back to the dispatch routine ? after allocating and queuing the workitem, I return STATUS_PENDING .

Now, because I’m in PASSIVE level, there can be a context switch from my dispatch routine to my workitem’s function, so it will run and complete the irp, before I return STATUS_PENDING from the dispatch routine. (it means that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I handle it?

thanks

Pankaj_Garg · March 8, 2006, 3:39pm

Gary,

It is mostly recommended to not hold any locks in a work item. The DDK says it can cause deadlock and i agree to it but i haven’t enumerated various cases which can cause deadlock. Anyways since workitem is running on system thread, its better to not hold a lock because it may adversely affect system performance as well.

In my practice, i have always found a solution without using locks.

–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…
You need to sync your work item at PASSIVE with other functions that can complete or cancel the IRP. The easiest way to do that, and is cross IRQL compatible, is to hold a spinlock any time the IRP is about to be manipulated; e.g. acquire the spinlock before you acquire the IRP. Cancel Safe Queues are great for this and KMDFs queuing mechanism appear to be even better.

Gary G. Little

------------------------------------------------------------------------------

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Wednesday, March 08, 2006 2:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoCompleteRequest() from WorkItem

Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the irp as a context and do some work in it. In the end of the workitem’s function, I complete the IRP.

Back to the dispatch routine - after allocating and queuing the workitem, I return STATUS_PENDING .

Now, because I’m in PASSIVE level, there can be a context switch from my dispatch routine to my workitem’s function, so it will run and complete the irp, before I return STATUS_PENDING from the dispatch routine. (it means that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I handle it?

thanks

— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Slava_Imameyev · March 8, 2006, 3:46pm

There is no problem. If you need to touch the Irp in your dispatch routine you can ( one of the following ):

set a Completion routine which signals to your dispatch routine and returns STATUS_MORE_PROCESSING_REQUIRED. You must free the Irp if you are the Irp creator or call IoCompleteRequest from your dispatch routine( i.e. you are not the Irp creator ).
synchronize the calling of the IoCompleteRequest with your dispatch routine.

If you want to wait only for an Irp completion and do not want to touch the Irp you can signal about the Irp completion from the completion routine and return STATUS_SUCCESS( from the completion routine ).
“Zed y” wrote in message news:xxxxx@ntdev…
Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the irp as a context and do some work in it. In the end of the workitem’s function, I complete the IRP.

Back to the dispatch routine ? after allocating and queuing the workitem, I return STATUS_PENDING .

Now, because I’m in PASSIVE level, there can be a context switch from my dispatch routine to my workitem’s function, so it will run and complete the irp, before I return STATUS_PENDING from the dispatch routine. (it means that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I handle it?

thanks

Gary_Little-2 · March 8, 2006, 4:10pm

My reading of the DDK does not say that. It says that the driver should
release any synchronization objects it holds before it calls
IoQueueWorkItem. You are dealing with an IRP that quite frequently is
completed by the DPC or a Cancel routine, and those are DISPATCH_LEVEL
functions, so the best way to sync with them is via a spinlock . unless
you write your own using an interlocked function, and that by definition
is a pain in the ass. Acquiring a spinlock that protects an IRP is the
only way I know of for a work item at PASSIVE to sync with a DPC at
DISPATCH.

Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Wednesday, March 08, 2006 2:39 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoCompleteRequest() from WorkItem

Gary,

It is mostly recommended to not hold any locks in a work item. The DDK
says it can cause deadlock and i agree to it but i haven’t enumerated
various cases which can cause deadlock. Anyways since workitem is running
on system thread, its better to not hold a lock because it may adversely
affect system performance as well.

In my practice, i have always found a solution without using locks.

–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…

You need to sync your work item at PASSIVE with other functions that can
complete or cancel the IRP. The easiest way to do that, and is cross IRQL
compatible, is to hold a spinlock any time the IRP is about to be
manipulated; e.g. acquire the spinlock before you acquire the IRP. Cancel
Safe Queues are great for this and KMDFs queuing mechanism appear to be
even better.

Gary G. Little

_____

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Wednesday, March 08, 2006 2:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoCompleteRequest() from WorkItem

Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the irp
as a context and do some work in it. In the end of the workitem’s
function, I complete the IRP.

Back to the dispatch routine - after allocating and queuing the workitem,
I return STATUS_PENDING .

Now, because I’m in PASSIVE level, there can be a context switch from my
dispatch routine to my workitem’s function, so it will run and complete
the irp, before I return STATUS_PENDING from the dispatch routine. (it
means that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I
handle it?

thanks

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · March 8, 2006, 4:13pm

If you are adding cancellation, the logic becomes tricky in the work item code to make sure the irp is still present, the dispatch routine code remains relatively the same, essentially

IoMarkIrpPending(Irp);

If (setting cancel routine fails) {
Set status in Irp
IoCompleteRequest(Irp);
}
Else {
Queue work item
}

Return STATUS_PENDING;

Note that once IoMarkIrpPending is called you must return STATUS_PENDING. If in between the queueing of the work item and returning STATUS_PENDING the irp is completed (or canceled if that is supported), there is no issue b/c you are not touching the irp in the dispatch routine after handing it off to the work item.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Wednesday, March 08, 2006 12:37 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoCompleteRequest() from WorkItem

You first mark the IRP pending by doing IoMarkIrpPending, then queue the work item and then you can safely return STATUS_PENDING. However, if your IRP is cancellable, the logic becomes little more tricky.

–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.
?
?
“Zed y” wrote in message news:xxxxx@ntdev…
Hi
?
Lets say I’m in PASSIVE IRQL in a dispatch function.
I mark my irp as pending. Later, I create a workitem that receives the irp as a context and do some work in it. In the end of the workitem’s function, I complete the IRP.
Back to the dispatch routine - after allocating and queuing the workitem, I return STATUS_PENDING .
?
Now, because I’m in PASSIVE level, there can be a context switch from my dispatch routine to my workitem’s function, so it will run and complete the irp, before I return STATUS_PENDING from the dispatch routine. (it means that when I return STATUS_PENDING, the irp is already completed!)
?
Is there a problem with the above scenario? And if so, how should I handle it?
?
thanks

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · March 8, 2006, 4:17pm

This is fine. Just don’t touch the IRP again in your dispatch routine
after you make the request avaialble to the work item, and don’t touch
it in the work item after you call IoCompleteRequest.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Wednesday, March 08, 2006 12:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoCompleteRequest() from WorkItem

Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the
irp as a context and do some work in it. In the end of the workitem’s
function, I complete the IRP.

Back to the dispatch routine - after allocating and queuing the
workitem, I return STATUS_PENDING .

Now, because I’m in PASSIVE level, there can be a context switch from my
dispatch routine to my workitem’s function, so it will run and complete
the irp, before I return STATUS_PENDING from the dispatch routine. (it
means that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I
handle it?

thanks
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · March 8, 2006, 4:17pm

I think it should be fine. Once you queue the workitem, if you are not
touching the IRP it should work fine. IoCompletionRoutine and IoCallDriver
return status are handled differently. I think you don’t need any
synchronization mechanism in the given situation.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Wednesday, March 08, 2006 12:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoCompleteRequest() from WorkItem

Hi

Lets say I’m in PASSIVE IRQL in a dispatch function.

I mark my irp as pending. Later, I create a workitem that receives the irp
as a context and do some work in it. In the end of the workitem’s function,
I complete the IRP.

Back to the dispatch routine - after allocating and queuing the workitem, I
return STATUS_PENDING .

Now, because I’m in PASSIVE level, there can be a context switch from my
dispatch routine to my workitem’s function, so it will run and complete the
irp, before I return STATUS_PENDING from the dispatch routine. (it means
that when I return STATUS_PENDING, the irp is already completed!)

Is there a problem with the above scenario? And if so, how should I handle
it?

thanks
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · March 8, 2006, 4:48pm

Gary is correct, you can acquire locks in work items. IIRC, the topic Pankaj is referring to states that you should not infinitely block in the work item, basically you should grab your lock, do your work, and then exit out in a timely fashion and not tie up the work item for a very long period of time since work items are a shared system resource.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@seagate.com
Sent: Wednesday, March 08, 2006 1:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IoCompleteRequest() from WorkItem

My reading of the DDK does not say that. It says that the driver should release any synchronization objects it holds before it calls IoQueueWorkItem. You are dealing with an IRP that quite frequently is completed by the DPC or a Cancel routine, and those are DISPATCH_LEVEL functions, so the best way to sync with them is via a spinlock … unless you write your own using an interlocked function, and that by definition is a pain in the ass. ?Acquiring a spinlock that protects an IRP is the only way I know of for a work item at PASSIVE to sync with a DPC at DISPATCH.
Gary G. Little

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Pankaj Garg
Sent: Wednesday, March 08, 2006 2:39 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoCompleteRequest() from WorkItem

Gary,
?
It is mostly recommended to not hold any locks in a work item. The DDK says it can cause deadlock and i agree to it but i haven’t enumerated various cases which can cause deadlock. Anyways since workitem is running on system thread, its better to not hold a lock because it may adversely affect system performance as well.
?
In my practice, i have always found a solution without using locks.

–
Pankaj Garg
This posting is provided “AS IS” with no warranties and confers no rights.
?
?
wrote in message news:xxxxx@ntdev…
You need to sync your work item at PASSIVE with other functions that can complete or cancel the IRP. The easiest way to do that, and is cross IRQL compatible, is to hold a spinlock any time the IRP is about to be manipulated; e.g. acquire the spinlock before you acquire the IRP. Cancel Safe Queues are great for this and KMDFs queuing mechanism appear to be even better.
Gary G. Little
________________________________________
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Wednesday, March 08, 2006 2:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoCompleteRequest() from WorkItem

Hi
?
Lets say I’m in PASSIVE IRQL in a dispatch function.
I mark my irp as pending. Later, I create a workitem that receives the irp as a context and do some work in it. In the end of the workitem’s function, I complete the IRP.
Back to the dispatch routine - after allocating and queuing the workitem, I return STATUS_PENDING .
?
Now, because I’m in PASSIVE level, there can be a context switch from my dispatch routine to my workitem’s function, so it will run and complete the irp, before I return STATUS_PENDING from the dispatch routine. (it means that when I return STATUS_PENDING, the irp is already completed!)
?
Is there a problem with the above scenario?? And if so, how should I handle it?
?
thanks
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

zedy · March 8, 2006, 8:22pm

Thank you all for your answers, they were very helpful.

Gary, i don’t understand one thing:
I mark the irp as pending and i pass it to my workitem. As long as I’m using
the irp and not passing it down to other drivers, why do i need to protect
it? (how can the irp be cancled or completed while i own it ?)

Another basic question:
Let’s say I’m a high level driver and i call IoCallDriver to pass an IRP
down
the stack, and the whole operation is synchronous.
There are several devices in the stack (let’s say A,B,C,D), each one of them
has a completion routine. after device D completes the irp, all completion
routines for all the devices are being called, and only afterwards all the
IoCallDriver() routines of all the devices return? (or if I’m wrong, what is
the right order?)

Thanks again guys.

On 3/8/06, xxxxx@seagate.com wrote:
>
> You need to sync your work item at PASSIVE with other functions that can
> complete or cancel the IRP. The easiest way to do that, and is cross IRQL
> compatible, is to hold a spinlock any time the IRP is about to be
> manipulated; e.g. acquire the spinlock before you acquire the IRP. Cancel
> Safe Queues are great for this and KMDFs queuing mechanism appear to be even
> better.
>
> Gary G. Little
> ------------------------------
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Zed y
> Sent: Wednesday, March 08, 2006 2:05 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] IoCompleteRequest() from WorkItem
>
>
>
> Hi
>
>
>
> Lets say I’m in PASSIVE IRQL in a dispatch function.
>
> I mark my irp as pending. Later, I create a workitem that receives the irp
> as a context and do some work in it. In the end of the workitem’s function,
> I complete the IRP.
>
> Back to the dispatch routine ? after allocating and queuing the workitem,
> I return STATUS_PENDING .
>
>
>
> Now, because I’m in PASSIVE level, there can be a context switch from my
> dispatch routine to my workitem’s function, so it will run and complete the
> irp, before I return STATUS_PENDING from the dispatch routine. (it means
> that when I return STATUS_PENDING, the irp is already completed!)
>
>
>
> Is there a problem with the above scenario? And if so, how should I
> handle it?
>
>
>
> thanks
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Misha_Karpin · March 9, 2006, 6:57am

That order is correct. If each IoCallDriver call returned status is
different than STATUS_PENDING, you are sure each corresponding completion
routine has been called and completed. If all this happen for all the
drivers in the stack, then D, C, B, and A completion routines will be called
before D dispatch routine finish and C IoCallDriver call complete, then B,
and so on.

I remember there was a very good paper on IRP completion from OSR, but I can
not locate it.

Thanks,
mK

Zed y wrote:

Another basic question:
Let’s say I’m a high level driver and i call IoCallDriver to pass an IRP
down the stack, and the whole operation is synchronous.
There are several devices in the stack (let’s say A,B,C,D), each one of them
has a completion routine. after device D completes the irp, all completion
routines for all the devices are being called, and only afterwards all the
IoCallDriver() routines of all the devices return? (or if I’m wrong, what is
the right order?)

FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Peter_Viscarola_OSR · March 9, 2006, 10:41pm

Well, it can certainly be cancelled (like, if the originating thread terminates)…

Peter
OSR

Doron_Holan · March 9, 2006, 10:52pm

To clarify:

it can be canceled at any time. the cancellation will have zero
affect if you have not set a cancellation routine
if you have set a cancel routine, the cancel routine can complete
the PIRP before the work item has run, otherwise if no cancel routine is
set, there is no way to complete the request before the work item runs
(assuming nothing else in your driver knows about the irp)

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, March 09, 2006 7:41 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IoCompleteRequest() from WorkItem

Well, it can certainly be cancelled (like, if the originating thread
terminates)…

Peter
OSR

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Maxim_S_Shatskih · March 10, 2006, 4:58am

>2) if you have set a cancel routine, the cancel routine can complete

the PIRP before the work item has run, otherwise if no cancel routine is
set, there is no way to complete the request before the work item runs

In fact, I should never use cancel routine for the IRP passed to the work item.

Cancel routine is used for indefinite blocking, like, say, read IRP on a
serial port - blocks till a byte will arrive from the wire.

Work item is not indefinite, it will fire very soon, maybe just after dropping
the IRQL to < DISPATCH.

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

zedy · March 13, 2006, 7:02am

So what you claim is that if i don’t have a cancel routine (that probably
completes the irp), i don’t need
to synchronize with it and gurd the irp. Well, this is the case, but i have
another question then:

Why do i (or drivers at all) need to have cancellation routine ? is the
only reason is to be more “friendly” to the operation system
and support “fast irp completion” in case of cancellation ? (if for
example, i process an irp in my TDI filter with no cancel routine and the
thread dies, what will happen? my filter will just continue to process it
regularly? )

And if i DO have a cancellation routine, whats the right way to synchronize
the irp with it ? (i need to acquire the CancelSpinlock inside the irp or
something like that ?)

Thanks again guys.

Misha_Karpin · March 13, 2006, 9:32am

I think these links are of your interest:

http://www.microsoft.com/whdc/driver/kernel/cancel_logic.mspx
http://www.microsoft.com/whdc/driver/kernel/Iocancel.mspx
http://www.microsoft.com/whdc/driver/kernel/IoCsq.mspx

De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de Zed y
Enviado el: lunes, 13 de marzo de 2006 13:02
Para: Windows System Software Devs Interest List
Asunto: Re: [ntdev] IoCompleteRequest() from WorkItem

So what you claim is that if i don’t have a cancel routine (that probably
completes the irp), i don’t need to synchronize with it and gurd the irp.
Well, this is the case, but i have another question then:

Why do i (or drivers at all) need to have cancellation routine ? is the
only reason is to be more “friendly” to the operation system and support
“fast irp completion” in case of cancellation ? (if for example, i process
an irp in my TDI filter with no cancel routine and the thread dies, what
will happen? my filter will just continue to process it regularly? )

And if i DO have a cancellation routine, whats the right way to synchronize
the irp with it ? (i need to acquire the CancelSpinlock inside the irp or
something like that ?)

Thanks again guys.

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/

Express yourself instantly with MSN Messenger! Download today it’s FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Doron_Holan · March 13, 2006, 11:14am

The basic idea is that you support cancellation when you pend a PIRP for an indefinite amount of time (let’s say waiting for your hardware to generate non deterministic amount of data). An app cannot exit if it has pending I/O in a driver. If you want to support cancellation, I would *highly* recommend using an IOCSQ and do *not* roll your own implementation. Alternatively, you can use KMDF which has support for cancellation built in.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Monday, March 13, 2006 4:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IoCompleteRequest() from WorkItem

So what you claim is that if i don’t have a cancel routine (that probably completes the irp), i don’t need
to synchronize with it and gurd the irp.? Well, this is the case, but i have another question then:
?
Why do i (or drivers at all) need to have cancellation routine ?? is the only reason is to be more “friendly” to the operation system
and support “fast irp completion” in case of cancellation ?? (if for example, i process an irp in my TDI filter with no cancel routine and the thread dies, what will happen?? my filter will just continue to process it regularly? )
?
And if i DO have a cancellation routine, whats the right way to?synchronize the irp with it ?? (i need to acquire the CancelSpinlock inside the irp or something like that ?)
?
Thanks again guys.
?
?
?
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Maxim_S_Shatskih · March 13, 2006, 7:07pm

>Why do i (or drivers at all) need to have cancellation routine ?

It is necessary to allow the app to be terminated while it is waiting for the
IRP to complete. So, if you pend the IRP indefinitely (waiting for data to
arrive from the network or other app on the local machine) - then it is a good
idea to have cancellation.

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