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
