When GR is running and attempting to clear up a node
if the node that is currently saved and we are coming
back to happens to be deleted during the time zebra
suspends the GR code due to hitting the node limit
then zebra GR code will just completely stop processing
and potentially leave stale nodes around forever.
Let's just remove this hole and process what we can.
Can you imagine trying to debug this after the fact?
If we remove a node then that counts toward the maximum
to process of ZEBRA_MAX_STALE_ROUTE_COUNT. This should
prevent any non-processing with a slightly larger cost
of having to look at a few nodes repeatedly
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The info->do_delete variable was being set to true only when
u.val was 1. The problem with this is that u.val is a union
and the various ways that we can call this event causes
different values to be written to the union value on the thread.
This makes no sense. Just set the variable to what we want it to
be when we need it to be true. Since it was only ever set during
a thread_execute section.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The safi has no 0 value which it is set to as part of the
initialization. Let's just set it to a sensible value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We copy the password only if an existing peer structure didn't have it.
But it might be the case when it exists, and we skip here.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
event_add_XXXX functions have no failure path where
if you pass in a double event pointer that it could
return without setting the pointer. As such these
asserts make no sense and are unnecessary
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
event_add_XXXX functions have no failure path where
if you pass in a double event pointer that it could
return without setting the pointer. As such these
asserts make no sense and are unnecessary
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
While C compilers will generally process strings across lines, we really
don't want that. I rather treat this as the indication of the typo it
probably is warn about it than support this odd C edge case.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The token value can be NULL if we run into something that failed to
parse. Throw a Python exception rather than SEGV.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Before it was setting SDIR, which is /usr/lib/frr, but the vtysh binary is put
under bindir (which is /usr/local by default). And running `/usr/lib/frr/frr reload`
failed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
It's not 4 bytes, it was assuming the same as Graceful-Restart tuples.
LLGR has more 3 bytes (Long-lived Stale Time).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
All the event changes exposed a bunch of places where
we were not properly following our standards. Just
clean them up in one big fell swoop.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
