HI, On Sat, Feb 11, 2023 at 02:22:13PM +0100, Maria Matejka wrote:
I'm still trying to find a convincing argument for why the bad case can never happen though. Can you think of a codepath that calls rt_notify with one of our own routes outside of us calling into rte_update*? I'm having a hard time reading the rt-table code, it just has so many twists and turns :)
This is definitely possible, think about this case:
protocol babel { preference 150; ... } protocol static { preference 200; ... }
$ show route X/Y via A, preference 200, protocol static [*] X/Y via B, preference 150, protocol babel
When Babel imports the route, it gets back (rt_notify) the static route which is best.
Then the admin requests "disable static1" and Babel gets (rt_notify) its own route without doing anything.
Ah, of course. That makes sense. I'll have to dig deeper into the object lifetimes then and keep the code more defensive for now.
And you should also be aware that in BIRD 3, you never get rt_notify while calling rte_update(); route updates are always asynchronous and you get them always in a clean context.
Interesting. I'll have to look at that. Speaking of bird v3, is it intentional that the branch for that isn't public? At least I couldn't find it when I last checked. Thanks, --Daniel