Don't auto set the thread->arg pointer. It is private
and should be only accessed through the THREAD_ARG pointer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Firstly, *keep no change* for `hash_get()` with NULL
`alloc_func`.
Only focus on cases with non-NULL `alloc_func` of
`hash_get()`.
Since `hash_get()` with non-NULL `alloc_func` parameter
shall not fail, just ignore the returned value of it.
The returned value must not be NULL.
So in this case, remove the unnecessary checking NULL
or not for the returned value and add `void` in front
of it.
Importantly, also *keep no change* for the two cases with
non-NULL `alloc_func` -
1) Use `assert(<returned_data> == <searching_data>)` to
ensure it is a created node, not a found node.
Refer to `isis_vertex_queue_insert()` of isisd, there
are many examples of this case in isid.
2) Use `<returned_data> != <searching_data>` to judge it
is a found node, then free <searching_data>.
Refer to `aspath_intern()` of bgpd, there are many
examples of this case in bgpd.
Here, <returned_data> is the returned value from `hash_get()`,
and <searching_data> is the data, which is to be put into
hash table.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Using memcmp is wrong because struct ipaddr may contain unitialized
padding bytes that should not be compared.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
Neither tabs nor newlines are acceptable in syslog messages. They also
break line-based parsing of file logs.
Signed-off-by: David Lamparter <equinox@diac24.net>
Recent changes to remove PRIu... in commit:
6cde4b4552
causes clang 11 to be unhappy, with length of field warnings.
Modify the offending code to compile properly using that compiler.
I've tested against clang 11 and gcc 9.3
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Previous patch was not sufficient to make sure the pointers get nulled.
Reason being is that vrrp_lookup_by_if_mvl() follows the link_ifindex on
the provided interface to acquire the base ifp, which is then used to
lookup the VR. However, because FRR's interface management is straight
up insane, it's possible that we delete the base interface before its
children. When this happens, link_ifindex is still valid for the macvlan
device but we have no interface corresponding to that ifindex, so our
lookup will fail. Consequently vrrp_lookup_by_if_mvl() can't be used if
we are handling deletion of any sort. Instead we have to loop through
every VR and check the pointers.
Also, there's no null check on the mvl_ifp pointer in vrrp_shutdown(),
and even though we log that we're returning early from it, we actually
don't. Do both of these things.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When we get a deletion notification for the macvlan device, we need to
do two things. First, down the VRRP session if it's up. Second, since
the mvl device is dynamic (i.e. not explicitly configured by FRR) it
will be deleted upon return from the callback, so we need to drop the
pointer to it. The checks for the first and second one were one check so
the pointer was only nulled when the session was already up, leading to
a later heap UAF on the mvl ifp.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
- Use correct units and conversions in model & code
- Fix incorrect CLI help string for V6 virtual addrs
- Fix nb get-entry callback for virtual router
- Fix a couple style nits
- Simplify some CLI code
- Remove unused code
- Remove unused YANG definitions
- Update sighup() to handle reloads
- Update interface level config writer to use NB callbacks
- Add simplified `no` forms for priority and advertisement-interval
commands
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
For some reason I made these functions require you to pass the correct
(v4 or v6) router when we could determine it from the type of address
passed; fix this
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
- Give the correct log message when refusing to start because the vr is
already started
- Fix a couple other : whynot; cases missed
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Due to some extremely shoddy programming on my part, the error messages
for certain errors was pretty much always wrong. We would start with the
correct error message, then on the next check, regardless of whether it
passed or failed, we would null out the error message, then on the next
one set it again (to the wrong message), then null it, and just keep
alternating. So errors were sometimes not being reported, sometimes
being reported correctly (if the condition parity happened to match the
appropriate condition), and sometimes being reported correctly.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Normally we only opportunistically try to bind interfaces to VRRP
instances upon getting if_add and if_up notifications; now that Zebra
sends if_down notifications when interfaces change while they are down,
we should try to bind when we get those as well.
This solves a bug where VRRP would not bind and activate virtual routers
to valid interfaces because their MACs were changed to VRRP macs while
the interface was down.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Suppress false positive on out of bounds access
* Suppress false positive on unchecked str2sockunion
* Remove self assignment
* Initialze struct msghdr to zero
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Handle kill signals by gracefully destroying all of our VRRP instances.
If any of them are in Master state, send an advert with 0 priority to
notify Backup routers we are going down.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Remove check for having at least 2 IPv6 addresses on the macvlan
device; this was only taking place in v6, and breaking the ability to
start VRRP on an IPv6 macvlan that was already set to protodown on
* Improve log messaging indicating that we cannot start because we
haven't got any VIPs configured
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Stupid stupid stupid. I can just bind to the Tx address right before I
Tx, since if I've gotten there I know my link is up.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
VRRPv2 uses the configured advertisement interval to compute the master
down timer, whereas VRRPv3 uses the one advertised by the master. Fix
computation to use the configured in in v2.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The RFC is not clear about how precise the skew time calculation should
be in VRRPv2. The advertisement interval is given in seconds, and the
field in the advertisement packet only supports non-fractional seconds,
so I was following this for calculating skew time as well. However the
skew time formula in vrrpv2 always yields a fractional amount of seconds
in the range (0-1), which right now means we always truncate to 0
seconds. I doubt this is what the RFC wanted so I'm allowing centisecond
precision for skew time.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
