In most situations, we don't expect that a flow we've successfully dumped, which we intend to delete, cannot be deleted. However, to make this code more resilient to ensure that ukeys *will* transition in all cases (including an error at this stage), grab the lock and transition this ukey forward to the evicted state, effectively treating a failure to delete as "this flow is already gone".
If we subsequently find out that it wasn't deleted, then that's ok - we will re-dump, and validate at that stage, which should lead to creating a new ukey or deleting the datapath flow when that happens. Signed-off-by: Joe Stringer <[email protected]> --- ofproto/ofproto-dpif-upcall.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c index 4a71bbe258df..bd324fbb6323 100644 --- a/ofproto/ofproto-dpif-upcall.c +++ b/ofproto/ofproto-dpif-upcall.c @@ -2227,6 +2227,11 @@ push_dp_ops(struct udpif *udpif, struct ukey_op *ops, size_t n_ops) if (op->dop.error) { /* flow_del error, 'stats' is unusable. */ + if (op->ukey) { + ovs_mutex_lock(&op->ukey->mutex); + transition_ukey(op->ukey, UKEY_EVICTED); + ovs_mutex_unlock(&op->ukey->mutex); + } continue; } -- 2.14.1 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
