> On May 21, 2015, at 12:54 PM, Sorin Vinturis > <svintu...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
