This specific Netdev leak is causing us stale VHU entries, where it
is showing false limit reaching maximum and preventing us to create
new entries for us. This leak can impact other nics also.
Steps to reproduce,
While running a test with a continous VM creation/deletion using an
orchestration script with-in cloud environment. In parallel we have
some monitoring script calling ovs-appctl dpctl/show stats commands
every minute.
Root-cause analysis,
During VHU port delete, one of netdev references were not reduced to
0 as show_dpif call has not given-up the reference back or doing bad
cleanup. This pending deference preventing VHU deletion sequence, this
is found to be one of corner case inside dpctl code which results in
leaking up netdev which ultimately results in stale VHU entry. After
fixing this problematic cleanup, issue is not seen.
Fixes: fceef2095222 ("dpctl: add ovs-appctl dpctl/* commands to talk to
dpif-netdev")
Signed-off-by: Vipul Ashri <[email protected]>
---
lib/dpctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dpctl.c b/lib/dpctl.c
index a70df5342..f764cf164 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -738,8 +738,8 @@ show_dpif(struct dpif *dpif, struct dpctl_params *dpctl_p)
continue;
}
error = netdev_get_stats(netdev, &s);
+ netdev_close(netdev);
if (!error) {
- netdev_close(netdev);
print_stat(dpctl_p, " RX packets:", s.rx_packets);
print_stat(dpctl_p, " errors:", s.rx_errors);
print_stat(dpctl_p, " dropped:", s.rx_dropped);
--
2.34.1.windows.1
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
