[ovs-dev] [PATCH] dpif-netlink-rtnl: Fix ovs_geneve probing after restart
u9012063 at gmail.com
Thu Oct 26 18:29:39 UTC 2017
On Thu, Oct 26, 2017 at 11:15 AM, Eric Garver <e at erig.me> wrote:
> On Thu, Oct 26, 2017 at 09:12:14AM -0700, William Tu wrote:
>> 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.
> I think that will work.
thanks, I will send out v2.
More information about the dev