On 21 March 2017 at 08:51, Paul Blakey <[email protected]> wrote: > > 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 <[email protected]> >> Signed-off-by: Joe Stringer <[email protected]> >> --- >> 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 <[email protected]>
Thanks for the confirmation, I applied this to master and branch-2.7. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
