Nithin, basically, any userspace code that used flows was commented out. And code that was trying to set qos to the netdev was commented out (because it was retrying forever). And netlink functions that used rtnetlink (were used for qos and netdev, if I am not mistaken) were commented out, so they do not get called.
So in principle, the functions in userspace that call into the kernel to add port, set port and delete port were reached, and thus were tested. I used only one bridge (in patch 00 I explained about problems with multiple bridges / multiple internal ports) - basically, I used only one, because otherwise it periodically re-tries the creation of the failed internal vport. I added manually the VM ports (used the WMI script as well). The "internal" port is created automatically by the userspace. I had tested the creation and destruction only. I.e. I did not test vxlan tunneling itself (I think this would be impossible at this stage), only that the vports are created and destroyed as they should. Regards, Sam ________________________________________ From: Alin Serdean Sent: Tuesday, September 30, 2014 6:23 PM To: Nithin Raju; Samuel Ghinet Cc: dev@openvswitch.org; Eitan Eliahu; Ankur Sharma Subject: RE: [PATCH 14/14] datapath-windows: Fix potential crash in OvsInitConfiguredSwitchNics: virtPort Hi Nithin, We used a modified version of netdev-windows. Alin. -----Mesaj original----- De la: Nithin Raju [mailto:nit...@vmware.com] Trimis: Tuesday, September 30, 2014 6:09 PM Către: Samuel Ghinet Cc: dev@openvswitch.org; Alin Serdean; Eitan Eliahu; Ankur Sharma Subiect: Re: [PATCH 14/14] datapath-windows: Fix potential crash in OvsInitConfiguredSwitchNics: virtPort On Sep 30, 2014, at 8:03 AM, Samuel Ghinet <sghi...@cloudbasesolutions.com> wrote: > If the hyper-v switch port type is external, then the function > OvsInitConfiguredSwitchNics allocates a vport, and if allocation > succeeds, it procedes with the initialization. However, at this point, > virtPort may happen to be null, but check against virtPort was not > made - this means that if virtPort was null, later on its fields would > try to be accessed. > > This patch adds a check for virtPort as well, so that the fields of > virtPort will not be accessed if virtPort is NULL. > > Signed-off-by: Samuel Ghinet <sghi...@cloudbasesolutions.com> hi Samuel, Thanks for the patch series. Can you pls. add some notes about validation performed. Did you make any userspace changes? thanks, Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
