On Mon, Jun 06, 2016 at 10:16:09AM -0500, Ryan Moats wrote:
> Ben Pfaff <b...@ovn.org> wrote on 06/02/2016 07:02:29 PM:
> > On Sun, May 22, 2016 at 04:36:19PM -0500, Ryan Moats wrote:
> > The following changes weren't immediately obvious to me, can you hint
> > about why they are needed?
> >
> > > diff --git a/ovn/controller/patch.c b/ovn/controller/patch.c
> > > index 4808146..e07e829 100644
> > > --- a/ovn/controller/patch.c
> > > +++ b/ovn/controller/patch.c
> > > @@ -185,7 +185,8 @@ add_bridge_mappings(struct controller_ctx *ctx,
> > > * to create patch ports for it. */
> > > continue;
> > > }
> > > - if (ld->localnet_port) {
> > > + if (ld->localnet_port && strcmp
> > (ld->localnet_port->logical_port,
> > > + binding->logical_port)) {
> > > static struct vlog_rate_limit rl =
> > VLOG_RATE_LIMIT_INIT(5, 1);
> > > VLOG_WARN_RL(&rl, "localnet port '%s' already set
> > for datapath "
> > > "'%"PRId64"', skipping the new port
> '%s'.",
>
> When I was running through the logic, I came across cases where I could
> re-enter this block with a logical port that had already been recorded
> in binding->logical_port previously. Rather than emit spurious warnings,
> I added the check on the logical_port name. I'm happy to add a comment
> to that effect in the next respin.
Please do, thanks!
> > > diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
> > > index 576c695..d1e8479 100644
> > > --- a/ovn/controller/physical.c
> > > +++ b/ovn/controller/physical.c
> > > @@ -310,7 +310,7 @@ physical_run(struct controller_ctx *ctx, enum
> > mf_field_id mff_ovn_geneve,
> > > if (!binding->chassis) {
> > > continue;
> > > }
> > > - if (localnet_port) {
> > > + if (localnet_port && localnet_port->logical_port) {
> > > ofport = u16_to_ofp(simap_get(&localvif_to_ofport,
> > >
> > localnet_port->logical_port));
> > > if (!ofport) {
>
> The issue I was running into was getting localnet_port structures with
> the logical_port pointer being invalidated and this was a check to make
> sure I didn't dump core. However I ended up reverting the change that
> caused this problem, so I think *this* one can go away. I'll double
> check and if it can't, I'll add a comment to that effect.
Thanks.
I'll look forward to v18.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
