The IGMP group could be accidentaly learned on LR datapath instead of LS. While the IGMP Group would be removed by northd if it was the case this still creates some churn in SB database. This could happen under the following conditions:
1) pinctrl thread will receive packet and stored IGMP group candidate in hmap, with datapath tunnel_key as key. 2) The LS datapath tunnel_key is reused by LR. 3) ovn-controller will proccess those changes and will run ip_mcast_sync(). 4) The ip_mcast_sync() will walk through IGMP group candidates retreiving datapath for given tunnel_key being LR at this point. 5) The IGMP group is stored in SB with a reference to LR. There is one more condition, the pinctrl thread can't run after 2) otherwise it would update the in memory ip_mcast_snoop map. To prevent that make sure we check if the retreived datapath is LS and skip the processing if that's not the case. Signed-off-by: Ales Musil <[email protected]> --- controller/pinctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/controller/pinctrl.c b/controller/pinctrl.c index fdb1527c1..eb9dd64d9 100644 --- a/controller/pinctrl.c +++ b/controller/pinctrl.c @@ -5769,7 +5769,7 @@ ip_mcast_sync(struct ovsdb_idl_txn *ovnsb_idl_txn, struct local_datapath *local_dp = get_local_datapath(local_datapaths, ip_ms->dp_key); - if (!local_dp) { + if (!local_dp || !local_dp->is_switch) { continue; } -- 2.51.1 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
