But this does not seem to work. When a 'OvsLookUpIPFwdInfo' fails, the forwarding request is enqueued with source port number set to 0 (https://github.com/openvswitch/ovs/blob/master/datapath-windows/ovsext/Geneve.c#L96).
As a result while cleaning up the forwarding entries, the function call 'OvsRemoveAllFwdEntriesWithPortNo' results in no operation, causing IpNeighboring entries and IpFwdEtnries to persist even after the deleting the adapter instance.
This could potential lead to a kernel crash, when resolving neighboring entries as it would access the stale instance.
aserdean
commented
5 years ago
When an adapter is down, all the forwarding entries and neighboring entries associated with the adapter instance should be cleaned up and the function 'OvsRemoveAllFwdEntriesWithPortNo' does the cleanup. (https://github.com/openvswitch/ovs/blob/master/datapath-windows/ovsext/IpHelper.c#L1888)
But this does not seem to work. When a 'OvsLookUpIPFwdInfo' fails, the forwarding request is enqueued with source port number set to 0 (https://github.com/openvswitch/ovs/blob/master/datapath-windows/ovsext/Geneve.c#L96). As a result while cleaning up the forwarding entries, the function call 'OvsRemoveAllFwdEntriesWithPortNo' results in no operation, causing IpNeighboring entries and IpFwdEtnries to persist even after the deleting the adapter instance.
This could potential lead to a kernel crash, when resolving neighboring entries as it would access the stale instance.