Hey Ben, Could you review this?
Thanks, Alex Wang, On Tue, Mar 25, 2014 at 2:24 PM, Alex Wang <[email protected]> wrote: > Commit 61057e884ca9c(ofproto-dpif-upcall: Slightly simplify > udpif_upcall_handler().) restructured the main loop in > udpif_upcall_handler() and discarded the check for the > 'exit_latch' after acquiring the mutex. This makes it > possible for the following race: > > - main thread sets the 'exit_latch' after the handler thread > checking it. > - main thread acquires the handler thread mutex and signals the > condition variable of handler thread. > - main thread releases the mutex and 'join' the handler thread. > - handler thread acquires the mutex, finds that n_upcalls is 0 > and waits on the signal of condition variable. > - then OVS will hang forever. > > This commit fixes the above issue by adding a check for the > 'exit_latch' after acquiring the mutex. > > Bug #1217229 > > Signed-off-by: Alex Wang <[email protected]> > --- > ofproto/ofproto-dpif-upcall.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c > index b931ab6..5b5fb6e 100644 > --- a/ofproto/ofproto-dpif-upcall.c > +++ b/ofproto/ofproto-dpif-upcall.c > @@ -695,7 +695,10 @@ udpif_upcall_handler(void *arg) > size_t i; > > ovs_mutex_lock(&handler->mutex); > - if (!handler->n_upcalls) { > + /* Must check the 'exit_latch' again to make sure the main thread > is > + * not joining on the handler thread. */ > + if (!handler->n_upcalls > + && !latch_is_set(&handler->udpif->exit_latch)) { > ovs_mutex_cond_wait(&handler->wake_cond, &handler->mutex); > } > > -- > 1.7.9.5 > >
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
