Nithin,
It seems that the locking is done by the caller to OvsGetExtInfoIoctl() but
this function releases the control lock (Line 1214) which was acquired by the
caller.
if (vport == NULL || (vport->ovsState != OVS_STATE_CONNECTED &&
vport->ovsState != OVS_STATE_NIC_CREATED)) {
NdisReleaseRWLock(gOvsSwitchContext->dispatchLock, &lockState);
NdisReleaseSpinLock(gOvsCtrlLock);
<<<--------------------------------------------------------
if (vportGet->portNo) {
OVS_LOG_WARN("vport %u does not exist any more", vportGet->portNo);
Eitan
-----Original Message-----
From: Nithin Raju
Sent: Thursday, October 30, 2014 10:09 AM
To: Eitan Eliahu
Cc: [email protected]
Subject: Re: [ovs-dev] [PATCH 2/3] datapath-windws: fix locking code in
OvsGetNetdevCmdHandler()
On Oct 30, 2014, at 8:27 AM, Eitan Eliahu <[email protected]>
wrote:
> Hi Nithin,
> Can you please revisit the locking sequence for the netdev handler?
> It seems that OvsGetVportDumpNext() is called with the two locks, Dispatch
> and Control held, (can we add a comment on it in the function header?).
> But, the Control lock is released at line 1214.
Eitan,
I have tried to follow the following sequence of acquiring locks during ioctl
calls:
- Acquire the control lock
- Acquire the dispatch lock for vport calls
- Release the dispatch lock
- Release the control lock
This patch I sent out for fixes in OvsGetNetdevCmdHandler() enforces this
sequence.
Are you saying that OvsGetVportDumpNext() does not adhere to this?
Thanks,
-- Nithin
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
