datapath-windows: Removed memory barrier and master lock

There is no need to enforce Netlink serialization on transactions sent from userspace. The access to the driver's shared resources is synchronized anyway. Thus I have removed the master lock. I also removed the memory barrier from filter dispatch routine. A memory barrier is already in place in OvsReleaseSwitchContext function, due to the use of InterlockedCompareExchange function. Signed-off-by: Sorin Vinturis <[email protected]> Acked-by: Eitan Eliahu <[email protected]> Signed-off-by: Ben Pfaff <[email protected]>
JerryChiao · May 27, 2015 · 8909c56 · 8909c56
1 parent 68f1df9
commit 8909c56
Show file tree

Hide file tree

Showing 2 changed files with 0 additions and 23 deletions.
diff --git a/datapath-windows/ovsext/Datapath.c b/datapath-windows/ovsext/Datapath.c
@@ -726,12 +726,6 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
         goto exit;
     }
 
-    /* Concurrent netlink operations are not supported. */
-    if (InterlockedCompareExchange((LONG volatile *)&instance->inUse, 1, 0)) {
-        status = STATUS_RESOURCE_IN_USE;
-        goto done;
-    }
-
     /*
      * Validate the input/output buffer arguments depending on the type of the
      * operation.
@@ -921,9 +915,6 @@ OvsDeviceControl(PDEVICE_OBJECT deviceObject,
     OvsReleaseSwitchContext(gOvsSwitchContext);
 
 exit:
-    KeMemoryBarrier();
-    instance->inUse = 0;
-
     /* Should not complete a pending IRP unless proceesing is completed. */
     if (status == STATUS_PENDING) {
         /* STATUS_PENDING is returned by the NL handler when the request is

diff --git a/datapath-windows/ovsext/Datapath.h b/datapath-windows/ovsext/Datapath.h
@@ -52,20 +52,6 @@ typedef struct _OVS_OPEN_INSTANCE {
     POVS_USER_PACKET_QUEUE packetQueue;
     UINT32 pid;
 
-    /*
-     * On platforms that support netlink natively, there's generally some form of
-     * serialization between concurrent calls to netlink sockets. However, OVS
-     * userspace guarantees that a given netlink handle is not concurrently used.
-     * Despite this, we do want to have some basic checks in the kernel to make
-     * sure that things don't break if there are concurrent calls.
-     *
-     * This is generally not an issue since kernel data structure access should
-     * be sychronized anyway. Only reason to have this safeguared is to protect
-     * the state in "state-aware" read calls which rely on previous state. This
-     * restriction might go away as the userspace code gets implemented.
-     */
-     INT inUse;
-
     struct {
         POVS_MESSAGE ovsMsg;    /* OVS message passed during dump start. */
         UINT32 index[2];        /* markers to continue dump from. One or more