On 20/03/2017 23:08, Joe Stringer wrote:
If a handler thread takes a long time to set up a set of flows, it is possible for one of the installed flows to be dumped and scheduled for deletion by a revalidator thread before the handler is able to transition the ukey into an operational state---Between the dpif_operate() above this function and the ukey lock / transition logic modified by this patch.Only transition the ukey for the flow if it wasn't already transitioned to a later state by a revalidator thread. Fixes: 54ebeff4c03d ("upcall: Track ukey states.") Reported-by: Paul Blakey <pa...@mellanox.com> Signed-off-by: Joe Stringer <j...@ovn.org> --- ofproto/ofproto-dpif-upcall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c index 07086ee385cc..0854807e4482 100644 --- a/ofproto/ofproto-dpif-upcall.c +++ b/ofproto/ofproto-dpif-upcall.c @@ -1404,7 +1404,7 @@ handle_upcalls(struct udpif *udpif, struct upcall *upcalls, ovs_mutex_lock(&ukey->mutex); if (ops[i].dop.error) { transition_ukey(ukey, UKEY_EVICTED); - } else { + } else if (ukey->state < UKEY_OPERATIONAL) { transition_ukey(ukey, UKEY_OPERATIONAL); } ovs_mutex_unlock(&ukey->mutex);
Tested-by: Paul Blakey <pa...@mellanox.com> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
