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@openvswitch.org Subject: Re: [ovs-dev] [PATCH 1/7] datapath-windows: fixes in OvsGetExtInfoIoctl() On Nov 12, 2014, at 9:48 AM, Eitan Eliahu <elia...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
