[ovs-dev] [PATCH 1/5] ofproto-dpif: Move send_packet() to ofproto-dpif-xlate module.

[Alex Wang]

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 <blp at 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 <blp at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20131001/decc507a/attachment-0003.html>