[ovs-dev] [PATCH] datapath-windows - fix crash when internal port is removed

Nithin Raju nithin at vmware.com
Fri Aug 1 00:01:27 UTC 2014


On Aug 1, 2014, at 12:17 AM, Eitan Eliahu <eliahue at vmware.com>
 wrote:

> BSOD while setting AllowManagementOS on $false #13
> https://urldefense.proofpoint.com/v1/url?u=https://github.com/openvswitch/ovs/issues/13&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=ubrOpIWavCMqX4l4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=nJEdnLEDoAOVUJoqVm4ZcqCMbQj8d7Tyr5bgPJbq7Qs%3D%0A&s=924730f29356b7532a8ebc6c80a2a68ef41cb31cf81fad50bdf450683db9e796
> 
> Signed-off-by: Eitan Eliahu <eliahue at vmware.com>
> Reported-by: Alin Serdean <aserdean at cloudbasesolutions.com>

Thanks for doing this.

I had the following comments.
1. Pls. remove the URL from the commit message. It is getting translated into something unfriendly. You can mention the Issue ID #13. You can also explain the issue if you wish.
2. The drop string can be "OVS-Dropped since internal port is absent.", to keep it consistent with the other strings.
3. Please also clear the tunnel context (tunnelTxNic at the least) using OvsClearTunCtx() before the function returns. The general pattern is that the lower layer function "consumes" the packet and the context it is supposed to consume. Currently OvsCompleteNBLForwardingCtx() is clearing the context, but I think we should remove that code, in the future.
4. It would be great if a counter could be added similar to ovsActions.failedEncap to indicate this issue. We'll figure out how to export all these counters to userspace as we go. A log message is also OK.

thanks,
Nithin




More information about the dev mailing list