[ovs-dev] [PATCH v5 1/4] datapath-windows: Support for custom VXLAN tunnel port

[Nithin Raju]

> On May 21, 2015, at 12:54 PM, Sorin Vinturis <svinturis at cloudbasesolutions.com> wrote:
> 
> Nithin,
> 
> I thought I have addressed your comment. My understanding was that was an issue in OvsDeleteVportCmdHandler() after the call to OvsRemoveAndDeleteVport(). The latter function might deallocate the vport, which would be used by the OvsTunnelVportPendingUninit() callback. I have modified OvsRemoveAndDeleteVport() to deallocate the vport only if the OvsCleanupVxlanTunnel() returns STATUS_SUCCESS. If OvsCleanupVxlanTunnel() returns STATUS_PENDING, then the vport is deallocated in OvsTunnelVportPendingUninit() callback.

Yes, you did address the issue w.r.t tunnel ports. A similar issue can occur with non-tunnel ports as well.

For instance, try this out:
1. Connect a VIF on the Hyper-V switch
2. Add the VIF to OVS.
3. Disconnect the VIF on the Hyper-V switch
4. Delete the VIF from OVS

Step #3 would call into OvsRemoveAndDeleteVport(), but the vport would not get deallocated since it is still present in OVS. When the vport gets deleted from OVS in step #4, we’d call into OvsRemoveAndDeleteVport() and that would deallocate the vport. Accessing the vport structure after the call to OvsRemoveAndDeleteVport() would cause a memory violation.

Hence my comment:
---
‘vport’ might have got freed up in OvsRemoveAndDeleteVport() which is why we were calling into OvsCreateMsgFromVport() earlier. This can happen if the port has been deleted from Hyper-V first, and then if it gets deleted from OVS userspace. I understand that the code will be sort of redundant in case the status is STATUS_PENDING, but it is a cost we have to pay, and is OK I think.
---

thanks,
-- Nithin