Download raw body.
bgpd: rework rde_enqueue_updates() to simplify the rib queue handling
bgpd: rework rde_enqueue_updates() to simplify the rib queue handling
bgpd: rework rde_enqueue_updates() to simplify the rib queue handling
> > > @@ -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.
bgpd: rework rde_enqueue_updates() to simplify the rib queue handling
bgpd: rework rde_enqueue_updates() to simplify the rib queue handling
bgpd: rework rde_enqueue_updates() to simplify the rib queue handling