Zebra has a shutdown setup where it asks the dplane to shutdown but can
still be processing data. This is especially true if something the dplane
is listening on receives data that will be processed by the main dplane thread
from netlink. When zebra_finalize is called it is possible that a bit
of data comes in before the zebra_dplane_shutdown() function is called
and the memory freed in ns_walk_func() causes the main dplane event
to crash when it cannot find the ns data anymore.
Reverse the order, stop the zebra dplane pthread and then free the
memory associated with the namespaces.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The wrong parameter is passed in `inet_ntop()` of `zfpm_log_route_info()` in
old fpm module, so the display of gateway is always wrong. Just remove
that extra ampersand.
Additionally, use "none" as gateway value for the case of no gateway.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
The early route queue has a series of `struct zebra_early_route *`
entries. Zebra is treating this memory as just a `struct route entry`.
This is wrong. Correct this to free the memory correctly.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The wq->spec.errorfunc is never used in the code.
It's been in the code base since 2005 and I also
do not remember ever seeing it being called. No
workqueue process function ever returns error.
Since it's not used let's just remove it from the
code base.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Address Sanitizer found this:
=================================================================
==418623==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 128 byte(s) in 4 object(s) allocated from:
#0 0x4bd732 in calloc (/usr/lib/frr/zebra+0x4bd732)
#1 0x7feaeab8f798 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27
#2 0x7feaeaba40f4 in nexthop_group_new /home/sharpd/frr8/lib/nexthop_group.c:270:9
#3 0x56859b in netlink_route_change_read_unicast /home/sharpd/frr8/zebra/rt_netlink.c:950:9
#4 0x5651c2 in netlink_route_change /home/sharpd/frr8/zebra/rt_netlink.c:1204:2
#5 0x54af15 in netlink_information_fetch /home/sharpd/frr8/zebra/kernel_netlink.c:407:10
#6 0x53e7a3 in netlink_parse_info /home/sharpd/frr8/zebra/kernel_netlink.c:1184:12
#7 0x548d46 in kernel_read /home/sharpd/frr8/zebra/kernel_netlink.c:501:2
#8 0x7feaeacc87f6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
#9 0x7feaeab36503 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3
#10 0x550d38 in main /home/sharpd/frr8/zebra/main.c:476:2
#11 0x7feaea492d09 in __libc_start_main csu/../csu/libc-start.c:308:16
Indirect leak of 576 byte(s) in 4 object(s) allocated from:
#0 0x4bd732 in calloc (/usr/lib/frr/zebra+0x4bd732)
#1 0x7feaeab8f798 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27
#2 0x7feaeab9b3f8 in nexthop_new /home/sharpd/frr8/lib/nexthop.c:373:7
#3 0x56875e in netlink_route_change_read_unicast /home/sharpd/frr8/zebra/rt_netlink.c:960:15
#4 0x5651c2 in netlink_route_change /home/sharpd/frr8/zebra/rt_netlink.c:1204:2
#5 0x54af15 in netlink_information_fetch /home/sharpd/frr8/zebra/kernel_netlink.c:407:10
#6 0x53e7a3 in netlink_parse_info /home/sharpd/frr8/zebra/kernel_netlink.c:1184:12
#7 0x548d46 in kernel_read /home/sharpd/frr8/zebra/kernel_netlink.c:501:2
#8 0x7feaeacc87f6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
#9 0x7feaeab36503 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3
#10 0x550d38 in main /home/sharpd/frr8/zebra/main.c:476:2
#11 0x7feaea492d09 in __libc_start_main csu/../csu/libc-start.c:308:16
SUMMARY: AddressSanitizer: 704 byte(s) leaked in 8 allocation(s).
Fix this!
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Read from the fpm dplane a route update that will
include status about whether or not the asic was
successfull in offloading the route.
Have this data passed up to zebra for processing and disseminate
this data as appropriate.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add the initial step of passing in a dplane context
to reading route netlink messages. This code
will be run in two contexts:
a) The normal pthread for reading netlink messages from
the kernel
b) The dplane_fpm_nl pthread.
The goal of this commit is too just allow a) to work
b) will be filled in in the future. Effectively
everything should still be working as it should
pre this change. We will just possibly allow
the passing of the context around( but not used )
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In order for a future commit to abstract the dplane_ctx_route_init
so that the kernel can use it, let's move some stuff around
and add a dplane_ctx_route_init_basic that can be used by multiple
different paths
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
create a dplane_ctx_route_init_basic so it can be used
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Zebra needs the ability to pass this data around.
Add it to the dplanes ability to pass.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
zebra: Add a dplane_ctx_set_flags
The dplane_ctx_set_flags call is missing, we will need it. Add it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If we have this semantics:
int ret = FAILURE;
if (foo)
goto done;
....
done:
return ret;
This pattern does us no favors and makes it harder to figure out what is going
on. Let's remove.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Volta submitted notification changes for the dplane that had a
special use case for their system. Volta is no more, the code
is not being actively developed and from talking with ex-Volta
employees there is no current plans to even maintain this code.
Wrap the special handling of nexthops that their asic-dataplane
did in a bit of code to isolate it and allow for future removal,
as that I do not actually believe anyone else is using this code.
Add a CPP_NOTICE several years into the future that will tell us
to remove the code. If someone starts using it then they will
have to notice this variable to set it and hopefully they will
see my CPP_NOTICE to come talk to us. If this is being used then
we can just remove this wrapper.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
On shutdown a use after free was being seen of a route table.
Basically the pointer was kept around and resent for cleanup.
Probably something needs to be unwound to make this better
in the future. Just cleaning up the use after free.
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-=================================================================
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929:==911929==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000127a00 at pc 0x7fb9ad546f5b bp 0x7ffc3cff0330 sp 0x7ffc3
cff0328
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-READ of size 8 at 0x606000127a00 thread T0
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #0 0x7fb9ad546f5a in route_table_free /home/sharpd/frr8/lib/table.c:103:13
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #1 0x7fb9ad546f04 in route_table_finish /home/sharpd/frr8/lib/table.c:61:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #2 0x6b94ba in zebra_ns_disable_internal /home/sharpd/frr8/zebra/zebra_ns.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #3 0x6b9158 in zebra_ns_disabled /home/sharpd/frr8/zebra/zebra_ns.c:116:9
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #4 0x7fb9ad43f0f5 in ns_disable_internal /home/sharpd/frr8/lib/netns_linux.c:273:4
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #5 0x7fb9ad43e634 in ns_disable /home/sharpd/frr8/lib/netns_linux.c:368:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #6 0x7fb9ad43e251 in ns_delete /home/sharpd/frr8/lib/netns_linux.c:330:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #7 0x7fb9ad43fbb3 in ns_terminate /home/sharpd/frr8/lib/netns_linux.c:524:3
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #8 0x54f8de in zebra_finalize /home/sharpd/frr8/zebra/main.c:232:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #9 0x7fb9ad5655e6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #10 0x7fb9ad3d3343 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #11 0x550b48 in main /home/sharpd/frr8/zebra/main.c:476:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #12 0x7fb9acd30d09 in __libc_start_main csu/../csu/libc-start.c:308:16
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #13 0x443549 in _start (/usr/lib/frr/zebra+0x443549)
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-0x606000127a00 is located 0 bytes inside of 56-byte region [0x606000127a00,0x606000127a38)
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-freed by thread T0 here:
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #0 0x4bd33d in free (/usr/lib/frr/zebra+0x4bd33d)
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #1 0x7fb9ad42cc80 in qfree /home/sharpd/frr8/lib/memory.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #2 0x7fb9ad547305 in route_table_free /home/sharpd/frr8/lib/table.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #3 0x7fb9ad546f04 in route_table_finish /home/sharpd/frr8/lib/table.c:61:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #4 0x6b94ba in zebra_ns_disable_internal /home/sharpd/frr8/zebra/zebra_ns.c:141:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #5 0x6b9692 in zebra_ns_early_shutdown /home/sharpd/frr8/zebra/zebra_ns.c:164:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #6 0x7fb9ad43f228 in ns_walk_func /home/sharpd/frr8/lib/netns_linux.c:386:9
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #7 0x55014f in sigint /home/sharpd/frr8/zebra/main.c:194:2
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #8 0x7fb9ad50db99 in frr_sigevent_process /home/sharpd/frr8/lib/sigevent.c:130:6
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #9 0x7fb9ad560d07 in thread_fetch /home/sharpd/frr8/lib/thread.c:1775:4
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #10 0x7fb9ad3d332d in frr_run /home/sharpd/frr8/lib/libfrr.c:1197:9
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #11 0x550b48 in main /home/sharpd/frr8/zebra/main.c:476:2
--
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #7 0x7fb9acd30d09 in __libc_start_main csu/../csu/libc-start.c:308:16
./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The `behavior usid` command is installed under the SRv6 Locator node in
the zebra VTY. However, in the SRv6 config write function this command
is wrongly put on the same line as the `prefix X:X::X:X/M` command.
This causes a failure when an SRv6 uSID locator is configured in zebra
and `frr-reload.py` is used to reload the FRR configuration.
This commit prepends a newline character to the `behavior usid` command
in the SRv6 config write function. The output of `show running-config`
before and after this commit is shown below.
Before:
```
Building configuration...
Current configuration:
!
frr version 8.5-dev
!
segment-routing
srv6
locators
locator loc1
prefix fc00:0:1::/48 block-len 32 node-len 16 behavior usid
exit
!
exit
!
exit
!
exit
!
end
```
After:
```
Building configuration...
Current configuration:
!
segment-routing
srv6
locators
locator loc1
prefix fc00:0:1::/48 block-len 32 node-len 16
behavior usid
exit
!
exit
!
exit
!
exit
!
end
```
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
If we enable MPLS for an interface via sysctl, we should write `mpls enable`,
not `mpls`.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The recent tracepoint additions in c317d3f246
did not properly setup the tracepoints for lttng. Fix this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This commit adds ZAPI encoders & decoders for traffic control operations, which
include tc_qdisc, tc_class and tc_filter.
Signed-off-by: Siger Yang <siger.yang@outlook.com>
This allows Zebra to manage QDISC, TCLASS, TFILTER in kernel and do cleaning
jobs when it starts up.
Signed-off-by: Siger Yang <siger.yang@outlook.com>
The latest FRR's frr-reload.py is broken and we can't reload FRR
gracefully with segment routing locator configuration (if we
execute frr-reload.py, FRR will stop suddenly).
The root cause of this issue is very simple. FRR will display the
current configuration like this (the below is the result of
"show running-configuration").
``
segment-routing
srv6
locators
locator default
prefix fd00:1:0:1::/64 block-len 40 node-len 24 func-bits 16
exit
!
exit
!
exit
!
exit
```
However, FRR doesn't accept segment routing locator parameters
if we specify block-len and node-len earlier than func-bits.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
Currently, in `zebra_srte_client_close_cleanup` we use the `RB_FOREACH`
macro to traverse the SR policies tree. We remove the SR policies within
the loop. Removing elements from the tree and freeing them is not safe
and causes a use-after-free crash whenever the
`zebra_srte_client_close_cleanup` is called to perform cleanup.
This commit replaces the `RB_FOREACH` macro with its variant
`RB_FOREACH_SAFE`. Unlike `RB_FOREACH`, `RB_FOREACH_SAFE` permits both
the removal of tree elements as well as freeing them from within the
loop safely.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
If you have this order in your configuration file:
no fpm use-next-hop-groups
fpm address 127.0.0.1
the dplane code was using the same event thread t_event and the second
add event in the code was going, you already have an event scheduled
and as such the second event does not overwrite it. Leaving
no code to actually start the whole processing. There are probably
other cli iterations that will cause this fun as well, but I'm
not going to spend the time sussing them out at the moment.
Fixes: #12314
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The API for configuring ES in zebra had a strict check for if_type
"isBond" that prevented the ES config from being created before the
interface.
Ticket: CM-29454
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Install a new command `behavior usid` into the `SRV6_LOC_NODE` CLI node.
This command allows the user to set/unset the `SRV6_LOCATOR_USID` flag
for an SRv6 locator. The `SRV6_LOCATOR_USID` flag indicates whether a
locator is a uSID locator or not. When the flag is set, the routing
daemons (e.g., bgpd) will install SRv6 behaviors with the uSID in the
dataplane.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
In this commit, we add two helper functions
`zebra_notify_srv6_locator_add` and `zebra_notify_srv6_locator_delete`.
These functions are used to notify locator additions/deletions to
zclients.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Fix the following build failure raised since version 8.4 and
d53dc9bd81:
zebra/netconf_netlink.c: In function 'netlink_netconf_change':
zebra/netconf_netlink.c:109:32: error: 'AF_MPLS' undeclared (first use in this function)
109 | if (ncm->ncm_family == AF_MPLS)
| ^~~~~~~
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
