[ovs-dev] [PATCH] dpif-netlink-rtnl: Fix ovs_geneve probing after restart

William Tu u9012063 at gmail.com
Thu Oct 26 16:12:14 UTC 2017

On Wed, Oct 25, 2017 at 10:39 AM, Eric Garver <e at erig.me> 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,
                                          (NLM_F_REQUEST | NLM_F_ACK
                                           | NLM_F_CREATE));

I'm testing using in-tree or out-of-tree and the result is consistent.


More information about the dev mailing list