Previously when updating vertices, edges and subnets, when no update was required
due to existing value matching the new one, memory associated with the new object
was not being freed leading to memory leaks. This commit fixes memory leak by
freeing memory associated with new object when update is unnecessary.
The ASan leak log for reference:
```
Direct leak of 312 byte(s) in 3 object(s) allocated from:
#0 0x7faf3afbfa37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7faf3ab5dbcf in qcalloc ../lib/memory.c:105
#2 0x7faf3ab42e00 in ls_parse_prefix ../lib/link_state.c:1323
#3 0x7faf3ab43c87 in ls_parse_msg ../lib/link_state.c:1373
#4 0x7faf3ab476a5 in ls_stream2ted ../lib/link_state.c:1885
#5 0x564e045046aa in sharp_opaque_handler ../sharpd/sharp_zebra.c:792
#6 0x7faf3aca35a9 in zclient_read ../lib/zclient.c:4410
#7 0x7faf3ac47474 in event_call ../lib/event.c:1979
#8 0x7faf3ab318b4 in frr_run ../lib/libfrr.c:1213
#9 0x564e044fdc6f in main ../sharpd/sharp_main.c:177
#10 0x7faf3a6f4d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 312 byte(s) leaked in 3 allocation(s).
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
This commit ensures proper cleanup by clearing the `algo->pdst` pointer if it points to a path that is being deleted.
It addresses memory leaks by freeing memory held by `algo->pdst` that might not have been released during the cleanup of processed paths.
The ASan leak log for reference:
```
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7fbffcec9a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fbffca67a81 in qcalloc ../lib/memory.c:105
#2 0x7fbffc9d1a54 in cpath_new ../lib/cspf.c:44
#3 0x7fbffc9d2829 in cspf_init ../lib/cspf.c:256
#4 0x7fbffc9d295d in cspf_init_v4 ../lib/cspf.c:287
#5 0x5601dcd34d3f in show_sharp_cspf_magic ../sharpd/sharp_vty.c:1262
#6 0x5601dcd2c2be in show_sharp_cspf sharpd/sharp_vty_clippy.c:1869
#7 0x7fbffc9afd61 in cmd_execute_command_real ../lib/command.c:993
#8 0x7fbffc9b00ee in cmd_execute_command ../lib/command.c:1052
#9 0x7fbffc9b0dc0 in cmd_execute ../lib/command.c:1218
#10 0x7fbffcb611c7 in vty_command ../lib/vty.c:591
#11 0x7fbffcb660ac in vty_execute ../lib/vty.c:1354
#12 0x7fbffcb6c4aa in vtysh_read ../lib/vty.c:2362
#13 0x7fbffcb51324 in event_call ../lib/event.c:1979
#14 0x7fbffca3b872 in frr_run ../lib/libfrr.c:1213
#15 0x5601dcd11c6f in main ../sharpd/sharp_main.c:177
#16 0x7fbffc5ffd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fbffcec9a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fbffca67a81 in qcalloc ../lib/memory.c:105
#2 0x7fbffca3c108 in list_new ../lib/linklist.c:49
#3 0x7fbffc9d1acc in cpath_new ../lib/cspf.c:47
#4 0x7fbffc9d2829 in cspf_init ../lib/cspf.c:256
#5 0x7fbffc9d295d in cspf_init_v4 ../lib/cspf.c:287
#6 0x5601dcd34d3f in show_sharp_cspf_magic ../sharpd/sharp_vty.c:1262
#7 0x5601dcd2c2be in show_sharp_cspf sharpd/sharp_vty_clippy.c:1869
#8 0x7fbffc9afd61 in cmd_execute_command_real ../lib/command.c:993
#9 0x7fbffc9b00ee in cmd_execute_command ../lib/command.c:1052
#10 0x7fbffc9b0dc0 in cmd_execute ../lib/command.c:1218
#11 0x7fbffcb611c7 in vty_command ../lib/vty.c:591
#12 0x7fbffcb660ac in vty_execute ../lib/vty.c:1354
#13 0x7fbffcb6c4aa in vtysh_read ../lib/vty.c:2362
#14 0x7fbffcb51324 in event_call ../lib/event.c:1979
#15 0x7fbffca3b872 in frr_run ../lib/libfrr.c:1213
#16 0x5601dcd11c6f in main ../sharpd/sharp_main.c:177
#17 0x7fbffc5ffd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
PBR configuration may specify "set nexthop blackhole" which,
for linux dataplanes, is implemented as a table with a blackhole
route.
Other dataplanes might implement this action as an explicit
packet-filtering "drop" action instead of a route. This new flag
PBR_ACTION_DROP is now set when a rule has "set nexthop blackhole"
as an aid to other dataplanes.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
With a negative form we get:
```
Internal CLI error [walltime_warning_str]
Internal CLI error [cputime_warning_str]
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before now, PBRD used non-zero values to imply that a rule's
match or action field was active. This approach was getting
cumbersome for fields where 0 is a valid active value and
various field-specific magic values had to be used.
This commit changes PBRD to use a flag bit per field to
indicate that the field is active.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
In the netlink-mediated kernel dataplane, each rule is stored
in either an IPv4-specific database or an IPv6-specific database.
PBRD opportunistically gleans each rule's address family value
from its source or destination IP address match value (if either
exists), or from its nexthop or nexthop-group (if it exists).
The 'family' value is particularly needed for netlink during
incremental rule deletion when none of the above fields remain set.
Before now, this address family has been encoded by occult means
in the (possibly otherwise unset) source/destination IP match
fields in ZAPI and zebra.
This commit documents the reasons for maintaining the 'family'
field in the PBRD rule structure, adds a 'family' field in the
common lib/pbr.h rule structure, and carries it explicitly in ZAPI.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
DSCP and ECN matching are configured independently. Maintain
these values in independent fields in pbrd, zapi, and zebra.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
After Zebra knows it's capability surrounding v6 with v4 nexthops
have it send this ability up to interested parties.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Include an event ptr-to-ptr in the event_execute() api
call, like the various schedule api calls. This allows the
execute() api to cancel an existing scheduled task if that
task is being executed inline.
Signed-off-by: Mark Stapp <mjs@labn.net>
Two changes for debug:
1. Add a field to indicate its vrf for nexthop. When the interface changes
vrf, we can't easily know the vrf of this nexthop according to current log.
2. Add a field to indicate operation type. We can't know whether to add or
remove route according to current log.
Before:
```
zebra_nhg_increment_ref: nhe 0x555623eb82c0 (76[if 6]) 0 => 1
zebra_interface_nhg_reinstall install nhe 75[77.75.1.75 if 6] nh type 3 flags 0x1
Route 77.75.1.0/24(8) queued for processing into sub-queue Early Route Processing
Route 77.75.1.0/24(8) queued for processing into sub-queue Early Route Processing
```
After:
```
zebra_nhg_increment_ref: nhe 0x555623eb82c0 (76[if 6 vrfid 9]) 0 => 1
zebra_interface_nhg_reinstall install nhe 75[77.75.1.75 if 6 vrfid 8] nh type 3 flags 0x1
Route 77.75.1.0/24(8) (add) queued for processing into sub-queue Early Route Processing
Route 77.75.1.0/24(8) (delete) queued for processing into sub-queue Early Route Processing
```
Signed-off-by: anlan_cs <anlan_cs@tom.com>
David rightly pointed out that having a test for fd > 0 would
technically not be right, but not wrong for this portion of the
code since we know that we would never get a fd = 0 in this section.
In any event let's make coverity happy and move on with our life.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgpd, pbrd: use common pbr encoder
zebra: use common pbr decoder
tests: pbr_topo1: check more filter fields
Purpose:
1. Reduce likelihood of zapi format mismatches when adding
PBR fields due to multiple parallel encoder implementations
2. Encourage common PBR structure usage among various daemons
3. Reduce coding errors via explicit per-field enable flags
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Subset: feature in PBR
New PBR rule fields:
match ip-protocol (was only tcp|udp, now any value in /etc/protocols)
match pcp (0-7)
match vlan (1-4094)
match vlan (tagged|untagged|untagged-or-zero)
Filter flags
Add filter_bm (flags) field internally to indicate which
filter fields should be considered active. Bit definitions
as in lib/pbr.h.
This commit uses only the PBR_FILTER_PCP bit, but other
fields will be added in future commits. (Fixes bug related
to determining set/not-set state of pcp filter)
Shift vlan filter flags to lib/pbr.h
Changes by:
Josh Werner <joshuawerner@mitre.org>
Eli Baum <ebaum@mitre.org>
G. Paul Ziemba <paulz@labn.net>
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
There's a workaround in the code from a bug from back in 2004, it ends
and re-enters config mode anytime an `exit` is done from a level below
the top-level config node (e.g., from a `router isis` node). We need to
re-enter config mode with or without a lock according to how we actually
entered it to begin with.
fixes#13920
Signed-off-by: Christian Hopps <chopps@labn.net>
The lock/unlocks are being done short-circuit so they are never pending;
however, the handling of the unlock notification was always resuming the command
if pending was set. In all cases pending is set for another command. For example
implicit commit locks then when notified its done unlocks which was clearing the
set-config pending flag and resuming that command incorrectly.
Signed-off-by: Christian Hopps <chopps@labn.net>
Currently, "on-match (next|goto)" only works if already present in a
route-map entry when the route-map is applied to the routes. However, if
the command is added to an existing route-map entry, the route-map is
not reapplied to the routes in order to accommodate the changes. And
service restart is needed. The problem is that setting the command
doesn't signal about the change to the listener (i.e. to a routing
daemon).
With this fix, signal to the listener about addition of "on-match
(next|goto)" to a route-map entry.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add support for "[no] ip ospf capbility opaque" at the interface
level with the default being capability opaque enabled. The command
"no ip ospf capability opaque" will disable opaque LSA database
exchange and flooding on the interface. A change in configuration
will result in the interface being flapped to update our options
for neighbors but no attempt will be made to purge existing LSAs
as in dense topologies, these may received by neighbors through
different interfaces.
Topotests are added to test both the configuration and the LSA
opaque flooding suppression.
Signed-off-by: Acee <aceelindem@gmail.com>
