To make sure I understand it right. You means: The main thread must delete all bridges (removing cfm/bfd on all ports, => remove the monitor thread) before removing the dpif.
Do i understand it right? If so, I think "dpif = xport->xbridge->dpif inside the lock" is thread-safe. On Tue, Oct 1, 2013 at 3:58 PM, Ben Pfaff <b...@nicira.com> wrote: > The logic that I was using is that either send_packet() is being > called from some thread other than the main one, in which case the > dpif is not being destroyed (because we would kill those threads > before destroying the dpif) or from the main thread, in which case > the dpif is not being destroyed (because we wouldn't be doing any > translation following destroying the dpif). > > Anyway, I don't actually care how we solve it (unlocking later is fine > too), I was just interested in whether my logic was correct. > > On Tue, Oct 01, 2013 at 03:47:16PM -0700, Ethan Jackson wrote: > > Technically I don't think it is because the dpif could be destroyed as > > soon as the xlate_rwlock is released. In practice this seems pretty > > unlikely. If we wanted to do that we'd have to ref count the dpif, > > which may not be a bad idea anyway. > > > > Ethan > > > > On Tue, Oct 1, 2013 at 3:45 PM, Ben Pfaff <b...@nicira.com> wrote: > > > On Tue, Oct 01, 2013 at 03:41:17PM -0700, Ethan Jackson wrote: > > >> > xlate_send_packet() locks xlate_rwlock before it looks up the xport, > > >> > but at the end it unlocks xlate_rwlock before it dereferences > > >> > xport->xbridge->dpif. Is the latter dereference safe, that is, does > > >> > anything guarantee that 'xport' and 'xbridge' aren't destroyed? > > >> > > >> No that's definitely not safe. Should be changed. > > > > > > Is it sufficient to do dpif = xport->xbridge->dpif inside the lock and > > > then use 'dpif' afterward? >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
