The use of iomarkirppending _processing

Iomarkirppending

VOID 
  iomarkirppending (in Out
  pirp  Irp
  );

Iomarkirppending marks the given IRP, indicating that a driver ' s Dispatch routine returned status_pending, because further Processing is required by the other driver routines. Parameters IRP Points to the IRP to be marked as pending. Include

Wdm.h or Ntddk.h Comments

Unless a driver calls IoCompleteRequest from it Dispatch routine with a given IRP or passes the IRP in to lower drivers, It must call iomarkirppending with the IRP. Otherwise, the I/O Manager attempts to complete the IRP as soon as the Dispatch routine.

If A driver queues incoming IRPs, it should call Iomarkirppending before the IT queues each IRP. Otherwise, an IRP could is dequeued, completed by another driver, and routine by the system freed the call to before Kirppending occurs, thereby causing a crash.

Any driver this sets an iocompletion routine in an IRP and then passes the IRP down to a lower driver should check the IRP ->pendingreturned flag in the IoCompletion routine. IF the flag is set, the IoCompletion routine must call iomarkirppending with the IRP. Note, however, the "a" driver that passes down the IRP and then waits on the "an event" should not mark the IRP pending. Instead, its iocompletion routine should signal the event and return status_more_processing_required.

A routine that calls Iomarkirppending must return status_pending.

Callers of Iomarkirppending must is running at IRQL <= Dispatch_level.

Many people are confused about the use of iomarkirppending. In fact, Iomarkirppending is a Microsoft-defined macro that resets the control domain of the IRP's current IO stack unit to sl_pending_returned, which is then checked by the IO Manager-if the IO Manager does not find this value, When the relevant routine returns (for example, a dispatch routine), the IO Manager proactively completes the IRP. The earliest meaning of introducing this function is for the processing of asynchronous IRP (such as IRP queuing, etc.). Many classic books include the DDK document that says: If a completion routine does not return status_more_processing_required, there are two statements in the completion routine:

if (irp->pendingreturned)
Iomarkirppending (IRP);

But none of these references are really clear about why. The real reason is:

Because the thread context that invokes iocompleterequest may be different from the thread context in which the IRP originated-the former may be in an interrupt-processing DPC thread, the latter may be in a read-write thread, At this time, a kernel-state APC will be iocompleterequest delivered in order to userevent the opaque domain of the IRP in the context of the thread that originated the IRP. However, in some cases, the thread context that invokes the iocompleterequest may be the same as the thread context in which the IRP originated, and Microsoft, in order to avoid unnecessary APC delivery in this case, It designs the IO Manager to check the control domain of the IRP's top IO stack unit-If the domain is sl_pending_returned, then the APC delivery is not delivered. Since the completion routine is called from the bottom of the IO stack to the top, it is possible to do sl_pending_returned in the completion routine, which is the reason for the two lines of code. (If a routine that initiates an IRP request, such as a dispatch routine) returns a status_pending, then irp->pendingreturned is set to true, which is used to determine whether the original request's initial state is PENDING by the completion routine.