Acked-by: Ankur Sharma <ankursha...@vmware.com> ________________________________________ From: dev <dev-boun...@openvswitch.org> on behalf of Eitan Eliahu <elia...@vmware.com> Sent: Wednesday, November 12, 2014 10:53 AM To: Nithin Raju Cc: dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH 1/7] datapath-windows: fixes in OvsGetExtInfoIoctl()
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 https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailman_listinfo_dev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=RDZsrBxhAiOewDSD-jiF-W03FqHevF2o7haW6eQzmtA&m=X4bvHrfC04vj7AbyZmn_AITD4zcwNIp57LWwgSQRYTM&s=8hdhppf6IzJNkiY3rexTqWVpRE-hm5tkoTCRBVxo-X0&e= _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
