On Thu, Oct 26, 2017 at 09:12:14AM -0700, William Tu wrote: > On Wed, Oct 25, 2017 at 10:39 AM, Eric Garver <[email protected]> wrote: > > On Tue, Oct 24, 2017 at 02:43:31PM -0700, William Tu wrote: > > > > Hi William, > > Thanks for taking a look at this. > > > >> When using the out-of-tree (openvswitch compat) geneve module, > >> the first time oot tunnel probing returns true (correct). > >> Without unloading the geneve module, if the userspace ovs-vswitchd > >> restarts, because the 'geneve_sys_6081' still exists, the probing > >> incorrectly returns false and loads the in-tree (upstream kernel) > >> geneve module. > > > > The reason for this is because rtnl sees the existing device and tries > > to call ->changelink, but since the out-of-tree tunnel has no handler it > > returns EOPNOTSUPP. > > > >> The patch fixes it by adding NLM_F_EXCL flags, so if geneve already > >> exists, the dpif_netlink_rtnl_create return EEXIST and the oot tunnel > >> probing returns true. To reproduce the issue, start the ovs > > > > While this fixes this scenario, it breaks another; an existing device > > in-tree/kernel geneve tunnel. We'll end up with the opposite occurring - > > it returns true when it should return false. > > > > So in addition to adding NLM_F_EXCL, this needs to also try to delete > > the existing device in the case of EEXISTS, then restart the probe. > > > > You're right, thanks! > How about we unconditionally delete the device before the probe?. I'm > simply adding one line without using NLM_F_EXCL: > > + dpif_netlink_rtnl_destroy(name); > error = dpif_netlink_rtnl_create(tnl_cfg, name, > OVS_VPORT_TYPE_GENEVE, > "ovs_geneve", > (NLM_F_REQUEST | NLM_F_ACK > | NLM_F_CREATE)); > > I'm testing using in-tree or out-of-tree and the result is consistent. >
I think that will work. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
