取消IRP－－2

It is standard practice for any IRP that is placed in a pending state on a device, to provide a cancel routine and make the IRP cancelable prior to entering the pending state. The most common example of this occurs when an IRP must be serialized, and is placed on a device queue to await its turn to be processed on the device. By placing the IRP into a cancelable state, the driver\'s responsiveness and flexibility are enhanced. If the issuer of the IRP determines that the IRP is no longer necessary, for instance the process that issued the IRP has been terminated, the IRP can be quickly disposed of on the device. In the case of a device queue, the IRP can be removed from the queue if it hasn\'t started on the device yet, and completed in a canceled state. In the above example of a terminating process, once all of the outstanding IRPs have been completed or canceled, the file handle to the device can be closed, and the process termination can continue to completion.

Waiting on a controller object to process an IRP is in a sense a pending state, for which one may consider trying to employ a cancel routine and making the IRP cancelable while waiting for the controller access to be granted. Of course this is not required, and the driver could take the approach that once a request has been queued to the controller object, it has been started on the device and cannot be canceled. This could pose a problem, however, if some device holds onto the controller object for a relatively long time, and outstanding IRPs from other devices that have queued requests to the controller cannot be canceled.

When attempting to make an IRP that is waiting on a controller object cancelable, there are several potential pitfalls that must be avoided. To understand what they are, one must first understand what happens when a request is queued on a controller object. Performing this action is done using the function IoAllocateController, which has the prototype:

VOID
IoAllocateController(
IN PCONTROLLER_OBJECT ControllerObject,
IN PDEVICE_OBJECT DeviceObject,
IN PDRIVER_CONTROL ExecutionRoutine,
IN PVOID Context
);

Notice that the function takes a pointer to the device object, which is queued on the controller object. What this actually means is important to understand. Within the call to IoAllocateController, the system takes the KDEVICE_QUEUE_ENTRY WaitQueueEntry member, located in the WAIT_CONTEXT_BLOCK structure, which is part of the DEVICE_OBJECT structure (see ntddk.h), and queues it to the KDEVICE_QUEUE DeviceWaitQueue member located in the controller\'s CONTROLLER_OBJECT structure.

An important point to note is that the DEVICE_OBJECT only contains one such entry, meaning that it can only be placed on the list once, otherwise the list will become corrupted. Furthermore, a device object can only be queued on a single list at any given time. Also note that this same technique is employed in the operation of DMA_ADAPTER objects, which make use of the same list entry in the device object.