Index | Thread | Search

From:
Theo Buehler <tb@theobuehler.org>
Subject:
Re: bgpd: rework rde_enqueue_updates() to simplify the rib queue handling
To:
tech@openbsd.org
Date:
Wed, 1 Jul 2026 10:24:04 +0200

Download raw body.

Thread
> > > @@ -588,7 +591,7 @@ prefix_evaluate(struct rib_entry *re, st
> > >  		/* no old path to remove and path is ineligible, skip rest */
> > >  		if (old_pathid_tx == 0 && new == NULL)
> > >  			return;
> > > -		rde_enqueue_updates(re, new, old_pathid_tx, EVAL_ALL);
> > > +		rde_enqueue_updates(re, peer, new, old_pathid_tx, EVAL_ALL);
> > 
> > While at this point we know old_pathid_tx != 0 || new != NULL, so we
> > know that peer has been initialized, this isn't super obvious and far
> > beyond gcc's deduction capabilities (both gcc 4.2.1 and 15.1 whine).
> > 
> > I don't see a good fix (if we do want to fix this). Doing peer = NULL
> > at the top and changing the above to
> > 
> >  		if ((old_pathid_tx == 0 && new == NULL) || peer == NULL)
> > 			return;
> > 
> > doesn't look like an improvement to me...
> 
> Hmmm. I'll have a closer look. We certainly can initalize peer = NULL at
> the top. Not sure if we need to check for peer == NULL though.

Then the "problem" becomes that rde_enqueue_updates(..., EVAL_ALL) may
deref peer, which again isn't obviously excluded.