On Fri, 25 Sep 2026 10:07:33 -0300, Lucas Vargas Dias wrote: > northd_handle_lr_changes() falls back to a full recompute when a deleted > logical router still has ports, since the ovn_ports it built can only be > torn down by a recompute - ovn_datapath_destroy() asserts on them. > > That check only looked at 'deleted_lr', the IDL's copy of the row from > before the deletion. If the LRP is removed in one transaction and the > router deleted in another, and northd processes both in the same > iteration, the row it sees no longer lists the port while the datapath > still holds it, and northd aborts: [...] > Check od->ports as well, so the fallback is driven by the ports northd > actually built.
Hi Lucas, Thanks for this. We have been hitting the same abort in production on 26.03, and I had an almost identical fix ready to send, so I am reporting here instead. On 26.03 the lflow node recomputes in the same run and walks lr_ports before the datapath is destroyed, so the abort shows up there first. Depending on the index of the removed datapath we have seen it as one of: assertion lr_stateful_rec failed in build_lbnat_lflows_iterate_by_lrp() assertion index < db->capacity failed in dynamic_bitmap_set1() assertion dp_bitmap_len failed in do_ovn_lflow_add() Our CMS tears down a gateway router with separate transactions for the router-type switch ports, the router ports and the router. ovn-northd aborted whenever the last of these transactions arrived while it was still busy with the previous ones, and the standby instance took over. I tested the patch on main (68936e39e) and on v26.03.3, where it also applies cleanly. On both trees the new test passes, and so does our own reproducer, which stops ovn-northd with SIGSTOP while the port deletion and the router deletion are committed as separate transactions, once for a router that holds the highest datapath index and once for one that does not. Without the patch that reproducer aborts on both trees. 'make check' on main with the patch applied: 1161 passed, 0 failed. We have been running an equivalent change on top of v26.03.3 since yesterday. Could this also go to branch-26.03? (The testing and this reply were done with help from Claude Opus 5.5 / Claude Code.) Tested-by: Bekei Park <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
