[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,
                                          "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.

Regards,
William


More information about the dev mailing list