[ovs-dev] [PATCH 1/7] datapath-windows: fixes in OvsGetExtInfoIoctl()

[Eitan Eliahu]

Yes, we planned to revisit and remove gOvsCtrlLock from all handlers (please see issue #53 an interface should not be created before the extension is enabled). But this function is called by a handler and there is no reason for it to assume gOvsCtrlLock is held.
Also, when should not assume DISPATCH level IRQL execution before holding the R/W Dispatch lock.
Besides that It is good.
Thanks,
Eitan

-----Original Message-----
From: Nithin Raju 
Sent: Wednesday, November 12, 2014 10:49 AM
To: Eitan Eliahu
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH 1/7] datapath-windows: fixes in OvsGetExtInfoIoctl()

On Nov 12, 2014, at 9:48 AM, Eitan Eliahu <eliahue at vmware.com> wrote:

> I don't see a reason why this function need to be called with gOvsCtrlLock held. The contention is on the Hyper-V VSwitch port when a port could be removed from a different thread context. But, this is taken care of by dispatch lock.

Sure, I plan to address the role for 'gOvsCtrlLock' in one sweep in the near future (as you know). Thanks for your input. I'll keep that in mind.

Until then, I don't want to let be the usages of 'gOvsCtrlLock'. Do the rest of the changes look ok?

Thanks,
-- Nithin