summaryrefslogtreecommitdiff
path: root/datapath-windows/ovsext/Datapath.c
diff options
context:
space:
mode:
authorEitan Eliahu <eliahue@vmware.com>2014-11-21 16:58:54 -0800
committerBen Pfaff <blp@nicira.com>2014-11-21 15:19:20 -0800
commit8ddda6853b1f69e5005a84de501ad87d0181d0f9 (patch)
tree34311be94dc1a6eb81154c440385c02abb1bde4a /datapath-windows/ovsext/Datapath.c
parentfaebf930196069f7ea2dc97ee3968698dcea84f2 (diff)
downloadopenvswitch-8ddda6853b1f69e5005a84de501ad87d0181d0f9.tar.gz
datapath-windows: do not complete an IRP when pending status returned
The driver completes a pending IRP, the IRP is being marked free by the I/O manager which causes a system crash when the IRP is completed at the second time. The driver should not complete a pending IRP in the context of the Device I/O control thread. *** Fatal System Error: 0x00000044 (0xFFFFFA800CF897D0,0x0000000000000F7A,0x0000000000000000,0x0000000000000000) Break instruction exception - code 80000003 (first chance) BugCheck 44, {fffffa800cf897d0, f7a, 0, 0} Probably caused by : OVSExt.sys ( OVSExt!OvsCompleteIrpRequest+3a ) Followup: MachineOwner --------- nt!DbgBreakPointWithStatus: fffff800`5a100930 cc int 3 11: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* MULTIPLE_IRP_COMPLETE_REQUESTS (44) A driver has requested that an IRP be completed (IoCompleteRequest()), but the packet has already been completed. This is a tough bug to find because the easiest case, a driver actually attempted to complete its own packet twice, is generally not what happened. Rather, two separate drivers each believe that they own the packet, and each attempts to complete it. The first actually works, and the second fails. Tracking down which drivers in the system actually did this is difficult, generally because the trails of the first driver have been covered by the second. However, the driver stack for the current request can be found by examining the DeviceObject fields in each of the stack locations. Arguments: Arg1: fffffa800cf897d0, Address of the IRP Arg2: 0000000000000f7a Arg3: 0000000000000000 Arg4: 0000000000000000 Signed-off-by: Eitan Eliahu <eliahue@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
Diffstat (limited to 'datapath-windows/ovsext/Datapath.c')
-rw-r--r--datapath-windows/ovsext/Datapath.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/datapath-windows/ovsext/Datapath.c b/datapath-windows/ovsext/Datapath.c
index bdbf72c27..49a0b68e6 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -864,6 +864,11 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
done:
KeMemoryBarrier();
instance->inUse = 0;
+
+ /* Should not complete a pending IRP unless proceesing is completed */
+ if (status == STATUS_PENDING) {
+ return status;
+ }
return OvsCompleteIrpRequest(irp, (ULONG_PTR)replyLen, status);
}