Donald Sharp [Thu, 27 Apr 2023 03:02:09 +0000 (23:02 -0400)]
zebra: Use zebra dplane for RTM link and addr
a) Move the reads of link and address information
into the dplane
b) Move the startup read of data into the dplane
as well.
c) Break up startup reading of the linux kernel data
into multiple phases. As that we have implied ordering
of data that must be read first and if the dplane has
taken over some data reading then we must delay initial
read-in of other data.
Fixes: #13288 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Thu, 20 Apr 2023 12:51:42 +0000 (08:51 -0400)]
zebra: Add code to get/set interface to pass up from dplane
1) Add a bunch of get/set functions and associated data
structure in zebra_dplane to allow the setting and retrieval
of interface netlink data up into the master pthread.
2) Add a bit of code to breakup startup into stages. This is
because FRR currently has a mix of dplane and non dplane interactions
and the code needs to be paused before continuing on.
Donald Sharp [Thu, 13 Apr 2023 20:43:27 +0000 (16:43 -0400)]
zebra: Remove duplicate function for netlink interface changes
Turns out FRR has 2 functions one specifically for startup
and one for normal day to day operations. There were only
a couple of minor differences from what I could tell, and
where they were different the after startup functionality should
have been updated too. I cannot figure out why we have 2.
Non-startup handling of bonds appears to be incorrect
so let's fix that. Additionally the speed was not
properly being set in non-startup situations.
Donald Sharp [Thu, 27 Apr 2023 03:25:27 +0000 (23:25 -0400)]
zebra: Rename vrf_lookup_by_tableid to zebra_vrf_lookup..
Rename the vrf_lookup_by_id function to zebra_vrf_lookup_by_id
and move to zebra_vrf.c where it nominally belongs, as that
we need zebra specific data to find this vrf_id and as such
it does not belong in vrf.c
Donald Sharp [Fri, 30 Jun 2023 13:56:51 +0000 (09:56 -0400)]
lib: Add two places we were not counting route-map applied
There were a couple of places where it was possible a route-map
was applied( and DENIED ) but the count for the number of times
the application happen was not incremented.
ryndia [Fri, 30 Jun 2023 11:02:27 +0000 (15:02 +0400)]
ospf6d: unlock lsa
The function ospf6_router_lsa_contains_adj(), ospf6_gr_check_adjs() and ospf6_find_interf_prefix_lsa() iterate through LSDB and lock each LSA. During testing, it was discovered that the lock count did not reach zero upon termination. The stack trace below indicates the leak. To resolve this issue, it was found that unlocking the LSA before returning from the functions solves the problem. This suggests that there was a missing unlock that caused the lock count to remain nonzero.
Direct leak of 400 byte(s) in 2 object(s) allocated from:
#0 0x7fa744ccea37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fa744867562 in qcalloc ../lib/memory.c:105
#2 0x555cdbb37506 in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:710
#3 0x555cdbb375d6 in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x555cdbaf1008 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x555cdbb48ceb in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x555cdbb4ac90 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x555cdbb4aecc in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7fa744950c33 in event_call ../lib/event.c:1995
#9 0x7fa74483b34a in frr_run ../lib/libfrr.c:1213
#10 0x555cdbacf1eb in main ../ospf6d/ospf6_main.c:250
#11 0x7fa7443f9d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fa744cce867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fa744867525 in qmalloc ../lib/memory.c:100
#2 0x555cdbb37520 in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:711
#3 0x555cdbb375d6 in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x555cdbaf1008 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x555cdbb48ceb in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x555cdbb4ac90 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x555cdbb4aecc in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7fa744950c33 in event_call ../lib/event.c:1995
#9 0x7fa74483b34a in frr_run ../lib/libfrr.c:1213
#10 0x555cdbacf1eb in main ../ospf6d/ospf6_main.c:250
#11 0x7fa7443f9d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Direct leak of 2000 byte(s) in 10 object(s) allocated from:
#0 0x7f2c3faeea37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f2c3f68a6d9 in qcalloc ../lib/memory.c:105
#2 0x56431b83633d in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:710
#3 0x56431b83640d in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x56431b7efe13 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x56431b847b31 in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x56431b849ad6 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x56431b849d12 in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7f2c3f773c62 in event_call ../lib/event.c:1995
#9 0x7f2c3f65e2de in frr_run ../lib/libfrr.c:1213
#10 0x56431b7cdff6 in main ../ospf6d/ospf6_main.c:221
#11 0x7f2c3f21dd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 460 byte(s) in 10 object(s) allocated from:
#0 0x7f2c3faee867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f2c3f68a69c in qmalloc ../lib/memory.c:100
#2 0x56431b836357 in ospf6_lsa_alloc ../ospf6d/ospf6_lsa.c:711
#3 0x56431b83640d in ospf6_lsa_create ../ospf6d/ospf6_lsa.c:725
#4 0x56431b7efe13 in ospf6_receive_lsa ../ospf6d/ospf6_flood.c:912
#5 0x56431b847b31 in ospf6_lsupdate_recv ../ospf6d/ospf6_message.c:1621
#6 0x56431b849ad6 in ospf6_read_helper ../ospf6d/ospf6_message.c:1896
#7 0x56431b849d12 in ospf6_receive ../ospf6d/ospf6_message.c:1925
#8 0x7f2c3f773c62 in event_call ../lib/event.c:1995
#9 0x7f2c3f65e2de in frr_run ../lib/libfrr.c:1213
#10 0x56431b7cdff6 in main ../ospf6d/ospf6_main.c:221
#11 0x7f2c3f21dd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Donald Sharp [Sat, 1 Jul 2023 15:18:06 +0000 (11:18 -0400)]
ospf6d: Fix crash because neighbor structure was freed
The loading_done event needs a event pointer to prevent
use after free's. Testing found this:
ERROR: AddressSanitizer: heap-use-after-free on address 0x613000035130 at pc 0x55ad42d54e5f bp 0x7ffff1e942a0 sp 0x7ffff1e94290
READ of size 1 at 0x613000035130 thread T0
#0 0x55ad42d54e5e in loading_done ospf6d/ospf6_neighbor.c:447
#1 0x55ad42ed7be4 in event_call lib/event.c:1995
#2 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#3 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#4 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#5 0x55ad42cf2b19 in _start (/usr/lib/frr/ospf6d+0x248b19)
0x613000035130 is located 48 bytes inside of 384-byte region [0x613000035100,0x613000035280)
freed by thread T0 here:
#0 0x7f57998d77a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
#1 0x55ad42e3b4b6 in qfree lib/memory.c:130
#2 0x55ad42d5d049 in ospf6_neighbor_delete ospf6d/ospf6_neighbor.c:180
#3 0x55ad42d1e1ea in interface_down ospf6d/ospf6_interface.c:930
#4 0x55ad42ed7be4 in event_call lib/event.c:1995
#5 0x55ad42ed84fe in _event_execute lib/event.c:2086
#6 0x55ad42d26d7b in ospf6_interface_clear ospf6d/ospf6_interface.c:2847
#7 0x55ad42d73f16 in ospf6_process_reset ospf6d/ospf6_top.c:755
#8 0x55ad42d7e98c in clear_router_ospf6_magic ospf6d/ospf6_top.c:778
#9 0x55ad42d7e98c in clear_router_ospf6 ospf6d/ospf6_top_clippy.c:42
#10 0x55ad42dc2665 in cmd_execute_command_real lib/command.c:994
#11 0x55ad42dc2b32 in cmd_execute_command lib/command.c:1053
#12 0x55ad42dc2fa9 in cmd_execute lib/command.c:1221
#13 0x55ad42ee3cd6 in vty_command lib/vty.c:591
#14 0x55ad42ee4170 in vty_execute lib/vty.c:1354
#15 0x55ad42eec94f in vtysh_read lib/vty.c:2362
#16 0x55ad42ed7be4 in event_call lib/event.c:1995
#17 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#18 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#19 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
previously allocated by thread T0 here:
#0 0x7f57998d7d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x55ad42e3ab22 in qcalloc lib/memory.c:105
#2 0x55ad42d5c8ff in ospf6_neighbor_create ospf6d/ospf6_neighbor.c:119
#3 0x55ad42d4c86a in ospf6_hello_recv ospf6d/ospf6_message.c:464
#4 0x55ad42d4c86a in ospf6_read_helper ospf6d/ospf6_message.c:1884
#5 0x55ad42d4c86a in ospf6_receive ospf6d/ospf6_message.c:1925
#6 0x55ad42ed7be4 in event_call lib/event.c:1995
#7 0x55ad42e1df75 in frr_run lib/libfrr.c:1213
#8 0x55ad42cf332e in main ospf6d/ospf6_main.c:250
#9 0x7f5798133c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Add an actual event pointer and just track it appropriately.
Donald Sharp [Fri, 30 Jun 2023 19:21:43 +0000 (15:21 -0400)]
ospf6d: Stop crash in ospf6_write
I'm seeing crashes in ospf6_write on the `assert(node)`. The only
sequence of events that I see that could possibly cause this to happen
is this:
a) Someone has scheduled a outgoing write to the ospf6->t_write and
placed item(s) on the ospf6->oi_write_q
b) A decision is made in ospf6_send_lsupdate() to send an immediate
packet via a event_execute(..., ospf6_write,....).
c) ospf6_write is called and the oi_write_q is cleaned out.
d) the t_write event is now popped and the oi_write_q is empty
and FRR asserts on the `assert(node)` <crash>
When event_execute is called for ospf6_write, just cancel the t_write
event. If ospf6_write has more data to send at the end of the function
it will reschedule itself. I've only seen this crash one time and am
unable to reliably reproduce this at all. But this is the only mechanism
that I can see that could make this happen, given how little the oi_write_q
is actually touched in code.
Chirag Shah [Thu, 29 Jun 2023 16:55:12 +0000 (09:55 -0700)]
tools: fix pim interface config deletion
When no ip pim is performed subsequent pim related
configs under the interface also implicitly deleted.
When doing this via frr-reload requires to remove any
explicit no ip pim <blah> lines so delete list.
Testing Done:
running-config:
interface lo
ip pim
ip pim use-source 6.0.0.1
exit
frr.conf:
remove two pim config lines.
interface lo
exit
Before fix:
2023-06-29 23:44:26,062 INFO: Failed to execute interface lo no ip pim use-source 6.0.0.1
2023-06-29 23:44:26,142 INFO: Failed to execute interface lo no ip pim use-source
2023-06-29 23:44:26,221 INFO: Executed "interface lo no ip pim"
After fix:
Only no ip pim executed and rest of the other lines removed from delete
list.
2023-06-30 01:07:32,618 INFO: Executed "interface lo no ip pim"
Donald Sharp [Thu, 29 Jun 2023 13:35:00 +0000 (09:35 -0400)]
zebra: Static routes async notification do not need this test
When using asic_offload with an asynchronous notification the
rib_route_match_ctx function is testing for distance and tag
being correct against the re.
Normal route notification for static routes is this(well really all routes):
a) zebra dplane generates a ctx to send to the dplane for route install
b) dplane installs it in the kernel
c) if the dplane_fpm_nl.c module is being used it installs it.
d) The context's success code is set to it worked and passes the context
back up to zebra for processing.
e) Zebra master receives this and checks the distance and tag are correct
for static routes and accepts the route and marks it installed.
If the operator is using a wait for install mechansim where the dplane
is asynchronously sending the result back up at a future time *and*
it is using the dplane_fpm_nl.c code where it uses the rt_netlink.c
route parsing code, then there is no way to set distance as that we
do not pass distance to the kernel.
As such static routes were never being properly handled since the re and
context would not match and the route would still be marked as queued.
Modify the code such that the asynchronous path notification for static
routes ignores the distance and tag's as that there is no way to test
for this data from that path at this point in time.
anlan_cs [Wed, 28 Jun 2023 04:31:52 +0000 (12:31 +0800)]
pbrd: fix crash with match command
Crash with empty `ip-protocol`:
```
anlan(config-pbr-map)# match ip-protocol
vtysh: error reading from pbrd: Resource temporarily unavailable (11)Warning: closing connection to pbrd because of an I/O error!
```
Donatas Abraitis [Tue, 27 Jun 2023 08:44:10 +0000 (11:44 +0300)]
zebra: Free Zebra client resources
Memory leaks started flowing:
```
AddressSanitizer Topotests Part 0: 15 KB -> 283 KB
AddressSanitizer Topotests Part 1: 1 KB -> 495 KB
AddressSanitizer Topotests Part 2: 13 KB -> 478 KB
AddressSanitizer Topotests Part 3: 39 KB -> 213 KB
AddressSanitizer Topotests Part 4: 30 KB -> 836 KB
AddressSanitizer Topotests Part 5: 0 bytes -> 356 KB
AddressSanitizer Topotests Part 6: 86 KB -> 783 KB
AddressSanitizer Topotests Part 7: 0 bytes -> 354 KB
AddressSanitizer Topotests Part 8: 0 bytes -> 62 KB
AddressSanitizer Topotests Part 9: 408 KB -> 518 KB
```
```
Direct leak of 3584 byte(s) in 1 object(s) allocated from:
#0 0x7f1957b02d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x559895c55df0 in qcalloc lib/memory.c:105
#2 0x559895bc1cdf in zserv_client_create zebra/zserv.c:743
#3 0x559895bc1cdf in zserv_accept zebra/zserv.c:880
#4 0x559895cf3438 in event_call lib/event.c:1995
#5 0x559895c3901c in frr_run lib/libfrr.c:1213
#6 0x559895a698f1 in main zebra/main.c:472
#7 0x7f195635ec86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
```
Fixes b20acd0 ("bgpd: Use synchronous way to get labels from Zebra")
Keelan10 [Mon, 26 Jun 2023 10:56:26 +0000 (14:56 +0400)]
pimd: Fix memory leak in PIM interface deletion
This commit ensures proper cleanup by deleting the gm_join_list when a PIM interface is deleted. The gm_join_list was previously not being freed, causing a memory leak.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in multicast_mld_join_topo1.test_multicast_mld_local_join/r1.asan.pim6d.28070
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230372180f in list_new lib/linklist.c:49
#3 0x56230361b589 in pim_if_gm_join_add pimd/pim_iface.c:1313
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288
#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 96 byte(s) in 4 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x562303721651 in listnode_new lib/linklist.c:71
#3 0x56230372182b in listnode_add lib/linklist.c:92
#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295
#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326
#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#7 0x562303767280 in nb_callback_create lib/northbound.c:1235
#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#15 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#16 0x5623036c6392 in cmd_execute lib/command.c:1221
#17 0x5623037e75da in vty_command lib/vty.c:591
#18 0x5623037e7a74 in vty_execute lib/vty.c:1354
#19 0x5623037f0253 in vtysh_read lib/vty.c:2362
#20 0x5623037db4e8 in event_call lib/event.c:1995
#21 0x562303720f97 in frr_run lib/libfrr.c:1213
#22 0x56230368615d in main pimd/pim6_main.c:184
#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288
#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f6f in cmd_execute_command lib/command.c:1072
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x562303721651 in listnode_new lib/linklist.c:71
#3 0x56230372182b in listnode_add lib/linklist.c:92
#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295
#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326
#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#7 0x562303767280 in nb_callback_create lib/northbound.c:1235
#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#15 0x5623036c5f6f in cmd_execute_command lib/command.c:1072
#16 0x5623036c6392 in cmd_execute lib/command.c:1221
#17 0x5623037e75da in vty_command lib/vty.c:591
#18 0x5623037e7a74 in vty_execute lib/vty.c:1354
#19 0x5623037f0253 in vtysh_read lib/vty.c:2362
#20 0x5623037db4e8 in event_call lib/event.c:1995
#21 0x562303720f97 in frr_run lib/libfrr.c:1213
#22 0x56230368615d in main pimd/pim6_main.c:184
#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 400 byte(s) leaked in 11 allocation(s).
***********************************************************************************
```
Chirag Shah [Mon, 26 Jun 2023 22:29:59 +0000 (15:29 -0700)]
zebra: fix evpn rmac nh list cmp function
EVPN RMAC (Router MAC) nexthop list compare
function needs to return all values so
the list element can be compared and added/deleted
properly.
Ticket:#3486989
Testing Done:
Originate EVPN Type-5 route with PIP IP and MAC as remote
nexthops.
Change the PIP IP address which triggers nexthop change.
Before fix:
When PIP IP changes RMAC is deleted from remote VTEPs.
TORS1# show evpn next-hops vni 4001 | include 00:02:00:00:00:2d
27.0.0.11 00:02:00:00:00:2d
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
00:02:00:00:00:2d 27.0.0.11
----- Remote VTEP change nexthop IP to 172.16.16.16 -----
TORS1# show evpn next-hops vni 4001 | include 00:02:00:00:00:2d
172.16.16.16 00:02:00:00:00:2d
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
TORS1#
After fix:
RMAC is retained as its nexthop list is not empty,
thus it is not deleted from remote VTEPs.
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
00:02:00:00:00:2d 172.16.16.16
Donald Sharp [Wed, 19 Apr 2023 12:13:18 +0000 (08:13 -0400)]
*: Rearrange vrf_bitmap_X api to reduce memory footprint
When running all daemons with config for most of them, FRR has
sharpd@janelle:~/frr$ vtysh -c "show debug hashtable" | grep "VRF BIT HASH" | wc -l
3570
3570 hashes for bitmaps associated with the vrf. This is a very
large number of hashes. Let's do two things:
a) Reduce the created size of the actually created hashes to 2
instead of 32.
b) Delay generation of the hash *until* a set operation happens.
As that no hash directly implies a unset value if/when checked.
This reduces the number of hashes to 61 in my setup for normal
operation.
add support of color extended community, conforming to RFC 9012.
This extended community will be added to the existing one, RT,SOO
and Node Target. The configuration will be made through the
route-map service.
Christian Hopps [Sun, 25 Jun 2023 12:13:25 +0000 (08:13 -0400)]
tools: less aggressive settings for clang-format
- Reports were that the current settings were choosing to extend beyond 80
columns too often. This change makes that more expensive but still tries
very hard to not break before first open parenthesis of function calls.
projects / mirror / frr.git / log