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 <svintu...@cloudbasesolutions.com>
---
datapath-windows/ovsext/Datapath.c | 9 ---------
datapath-windows/ovsext/Datapath.h | 14 --------------
2 files changed, 23 deletions(-)
diff --git a/datapath-windows/ovsext/Datapath.c
b/datapath-windows/ovsext/Datapath.c
index 7646f0a..e8aaf88 100644
--- a/datapath-windows/ovsext/Datapath.c
+++ b/datapath-windows/ovsext/Datapath.c
@@ -727,12 +727,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.
@@ -922,9 +916,6 @@ done:
OvsReleaseSwitchContext(gOvsSwitchContext);
exit:
- KeMemoryBarrier();
- instance->inUse = 0;
-
/* Should not complete a pending IRP unless proceesing is completed */
if (status == STATUS_PENDING) {
return status;
diff --git a/datapath-windows/ovsext/Datapath.h
b/datapath-windows/ovsext/Datapath.h
index dbc9dea..2c61d82 100644
--- 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
--
1.9.0.msysgit.0
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
