[ovs-git] [openvswitch/ovs] 8ddda6: datapath-windows: do not complete an IRP when pend...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: 8ddda6853b1f69e5005a84de501ad87d0181d0f9
      https://github.com/openvswitch/ovs/commit/8ddda6853b1f69e5005a84de501ad87d0181d0f9
  Author: Eitan Eliahu <eliahue at vmware.com>
  Date:   2014-11-21 (Fri, 21 Nov 2014)

  Changed paths:
    M datapath-windows/ovsext/Datapath.c

  Log Message:
  -----------
  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 at vmware.com>
Acked-by: Nithin Raju <nithin at vmware.com>
Signed-off-by: Ben Pfaff <blp at nicira.com>