summaryrefslogtreecommitdiffstats
path: root/zebra (follow)
Commit message (Collapse)AuthorAgeFilesLines
* add cplusplus guards to all zebra headersEmanuele Di Pascale2019-03-2542-2/+343
| | | | Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
* Merge pull request #3927 from donaldsharp/rnh_cleanupDavid Lamparter2019-03-221-7/+9
|\ | | | | zebra: Cleanup rnh table information before deleting underlying tables
| * zebra: Cleanup rnh table information before deleting underlying tablesDonald Sharp2019-03-081-7/+9
| | | | | | | | | | | | | | Cleaup the rnh tables on shutdown before we cleanup tables. As that this will remove any need to do rnh processing as part of shutdown. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | Revert "Merge pull request #3982 from pacovn/Coverity_1479148_copy_paste"Quentin Young2019-03-201-1/+1
| | | | | | | | | | This reverts commit 3a3704fe365a25b9644a938f674effb3e6084c56, reversing changes made to 5a3c6e736dca3639a1b49cdf305b909736f721de.
* | zebra: copy-paste error (Coverity 1479148)F. Aragon2019-03-201-1/+1
| | | | | | | | Signed-off-by: F. Aragon <paco@voltanet.io>
* | Merge pull request #3960 from donaldsharp/connectedMark Stapp2019-03-191-1/+1
|\ \ | | | | | | zebra: System routes sometimes can not be properly selected
| * | zebra: System routes sometimes can not be properly selectedDonald Sharp2019-03-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | System Routes if received over the netlink bus in a specific pattern that causes an update operation for that route in zebra can leave the dest->selected_fib pointer NULL, while having the ZEBRA_FLAG_SELECTED flag set. Specifically one way to achieve this is to do this: `ip addr del 4.5.6.7/32 dev swp1 ; ip addr add 4.5.6.7/32 dev swp1 metric 9` Why is this a big deal? Because nexthop tracking is looking at ZEBRA_FLAG_SELECTED to know if we can use a route, while nexthop active checking uses dest->selected_fib. So imagine we have bgp registering a nexthop. nexthop tracking in the above case will be able to choose the 4.5.6.7/32 route if that is what the nexthop is, due to the ZEBRA_FLAG_SELECTED being properly set. BGP then allows the peers connection to come up and we install routes with a 4.5.6.7 nexthop. The rib processing for route installation will then look at the 4.5.6.7 route see no dest->selected_fib and then start walking up the tree to resolve the route. In our case we could easily hit the default route and be unable to resolve the route. Which then becomes inactive in the rib so we never attempt to install it. This commit fixes this problem because when the rib_process decides that we need to update the fib( ie replace old w/ new ), the replacement with new was not setting the `dest->selected_fib` pointer to the new route_entry, when the route was a system route. Ticket: CM-24203 Signed-off-by: Donald Sharp <sharpd@cumulusnetworkscom>
* | | Merge pull request #3963 from AnuradhaKaruppiah/dad-fixesSri Mohana Singamsetty2019-03-171-0/+1
|\ \ \ | | | | | | | | zebra: EVPN DAD trigger was causing zebra to crash
| * | | zebra: EVPN DAD trigger was causing zebra to crashAnuradha Karuppiah2019-03-151-0/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Duplicate address detection and recovery was relying on the l2-vni backptr in the neighbor entry which was simply not initialized resulting in a NULL pointer access in a setup with dup-addressed VMs - VM1:{IP1,M1} and VM2:{IP1,M2} Call stack: (gdb) bt 6 at lib/sigevent.c:249 nbr=nbr@entry=0x559347f901d0, vtep_ip=..., vtep_ip@entry=..., do_dad=do_dad@entry=true, is_dup_detect=is_dup_detect@entry=0x7ffc7f6be59f, is_local=is_local@entry=true) at ./lib/ipaddr.h:86 ip=0x7ffc7f6be6f0, ifp=0x559347f901d0, zvni=0x559347f86800) at zebra/zebra_vxlan.c:3152 (More stack frames follow...) (gdb) p nbr->zvni $8 = (zebra_vni_t *) 0x0 <<<<<<<<<<<<<<<<<<<< (gdb) Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* | | Merge pull request #3949 from qlyoung/remove-zlog-newlinesSri Mohana Singamsetty2019-03-157-11/+11
|\ \ \ | | | | | | | | *: remove trailing newlines from zlog messages
| * | | *: remove trailing newlines from zlog messagesQuentin Young2019-03-147-11/+11
| |/ / | | | | | | | | | | | | | | | Zlog puts its own newlines on, and doing this makes logs look nasty. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* | | Merge pull request #3892 from vivek-cumulus/evpn_vrf_route_leakSri Mohana Singamsetty2019-03-151-4/+4
|\ \ \ | |/ / |/| | Leaking of EVPN-based IPv4 and IPv6 routes between VRFs
| * | zebra: Use next hop's VRF for EVPN-based routesvivek2019-03-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that the next hop's VRF is used for IPv4 and IPv6 unicast routes sourced from EVPN routes, for next hop and Router MAC tracking and install. This way, leaked routes from other instances are handled properly. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | Merge pull request #3893 from mjstapp/dplane_pw_nexthopsDonald Sharp2019-03-124-26/+84
|\ \ \ | | | | | | | | zebra: include nexthop info when installing pseudowires
| * | | zebra: use const in dplane pw nhlfe accessorsMark Stapp2019-03-074-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use const in the accessors for pseudowire nhlfe data; pull that through the kernel-facing apis that use that data. Signed-off-by: Mark Stapp <mjs@voltanet.io>
| * | | zebra: dplane pseudowires including nexthop infoMark Stapp2019-03-072-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add nexthop info to the data that the zebra dataplane captures when programming pseudowires. Signed-off-by: Mark Stapp <mjs@voltanet.io>
| * | | zebra: rename pseudowire destination apiMark Stapp2019-03-073-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In prep for adding nexthop info for pws, rename the accessor for the pw destination. Add a nexthop-group to the pw data in the dataplane module. Signed-off-by: Mark Stapp <mjs@voltanet.io>
* | | | Merge pull request #3908 from Tuetuopay/fix-unnumbered-no-ipDonald Sharp2019-03-121-1/+1
|\ \ \ \ | | | | | | | | | | zebra: Treat ifaces withouth IPv4 as unnumbered
| * | | | zebra: Treat ifaces withouth IPv4 as unnumberedTuetuopay2019-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current definition of an unnumberd interface as an interface with a /32 IPv4 is too restrictive, especially for EVPN symmetric routing since commit 2b83602b2 "*: Explicitly mark nexthop of EVPN-sourced routes as onlink". It removes the bypass check wether the nexthop is an EVPN VTEP, and relies on the SVI to be unnumberd to bypass the gateway lookup. While this works great if the SVI has an IP, it might not, and the test falls flat and EVPN type 5 routes are not installed into the RIB. Sample interface setup, where vxlan-blue is the L3VNI and br-blue the SVI: +----------+ | | | vrf-blue | | | +---+--+---+ | | +-------+ +-----------+ | | +----+----+ +---------+---------+ | | | br1 | | br-blue | | 10.0.0.1/24 | | | +-+-------+-------+-+ +----+----+ | | | | | | | +-----+------+ +-----+--+ +--+---+ +-+----+ | | | | | | | | | vxlan-blue | | vxlan1 | | eth1 | | eth2 | | | | | | | | | +------------+ +--------+ +------+ +------+ For inter-VNI routing, the SVI has no reason to have an IP, but it still needs type-5 routes from remote VTEPs. This commit expands the definition of an unnumberd interface to an interface having a /32 IPv4 or no IPv4 at all. Signed-off-by: Tuetuopay <tuetuopay@me.com>
* | | | | zebra: Allow json output to give a bit more dataDonald Sharp2019-03-101-0/+5
| |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | The dest->selected_fib should be reported in json output so that we can debug subtle conditions a bit better in the future. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | | Merge pull request #3889 from donaldsharp/rnh_vrf_down_stuffMark Stapp2019-03-083-6/+30
|\ \ \ \ | | | | | | | | | | zebra Rnh vrf down stuff
| * | | | zebra: Upon vrf deletion, actually release this data.Donald Sharp2019-03-013-6/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a vrf is deleted we need to tell the zebra_router that we have finished using the tables we are keeping track of. This will allow us to properly cleanup the data structures associated with them. This fixes this valgrind error found: ==8579== Invalid read of size 8 ==8579== at 0x430034: zvrf_id (zebra_vrf.h:167) ==8579== by 0x432366: rib_process (zebra_rib.c:1580) ==8579== by 0x432366: process_subq (zebra_rib.c:2092) ==8579== by 0x432366: meta_queue_process (zebra_rib.c:2188) ==8579== by 0x48C99FE: work_queue_run (workqueue.c:291) ==8579== by 0x48C3788: thread_call (thread.c:1607) ==8579== by 0x48A2E9E: frr_run (libfrr.c:1011) ==8579== by 0x41316A: main (main.c:473) ==8579== Address 0x5aeb750 is 0 bytes inside a block of size 4,424 free'd ==8579== at 0x4839A0C: free (vg_replace_malloc.c:540) ==8579== by 0x438914: zebra_vrf_delete (zebra_vrf.c:279) ==8579== by 0x48C4225: vrf_delete (vrf.c:243) ==8579== by 0x48C4225: vrf_delete (vrf.c:217) ==8579== by 0x4151CE: netlink_vrf_change (if_netlink.c:364) ==8579== by 0x416810: netlink_link_change (if_netlink.c:1189) ==8579== by 0x41C1FC: netlink_parse_info (kernel_netlink.c:904) ==8579== by 0x41C2D3: kernel_read (kernel_netlink.c:389) ==8579== by 0x48C3788: thread_call (thread.c:1607) ==8579== by 0x48A2E9E: frr_run (libfrr.c:1011) ==8579== by 0x41316A: main (main.c:473) ==8579== Block was alloc'd at ==8579== at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==8579== by 0x48A6030: qcalloc (memory.c:110) ==8579== by 0x4389EF: zebra_vrf_alloc (zebra_vrf.c:382) ==8579== by 0x438A42: zebra_vrf_new (zebra_vrf.c:93) ==8579== by 0x48C40AD: vrf_get (vrf.c:209) ==8579== by 0x415144: netlink_vrf_change (if_netlink.c:319) ==8579== by 0x415E90: netlink_interface (if_netlink.c:653) ==8579== by 0x41C1FC: netlink_parse_info (kernel_netlink.c:904) ==8579== by 0x4163E8: interface_lookup_netlink (if_netlink.c:760) ==8579== by 0x42BB37: zebra_ns_enable (zebra_ns.c:130) ==8579== by 0x42BC5E: zebra_ns_init (zebra_ns.c:208) ==8579== by 0x4130F4: main (main.c:401) This can be found by: `ip link del <VRF DEVICE NAME>` then `ip link add <NAME> type vrf table X` again and then attempting to use the vrf. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | | | zebra: Add some debugs to neighbor entry processingDonald Sharp2019-03-082-34/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get a neighbor entry in zebra we start processing it. Let's add some additional debugs to the processing so that when it bails out and we don't use the data, we know the reason. This should help in debugging the problems from why bgp does not appear to have data associated with a neighbor entry in the kernel. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | | | zebra: Remove duplicate NUD_PERMANENT checkDonald Sharp2019-03-081-4/+0
| |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | The check for an entry being NUD_PERMANENT has already been done there is no need to do it twice. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | | zebra: Remove unused sockaddr variableStephen Worley2019-03-061-6/+0
| |/ / |/| | | | | | | | | | | | | | This variable does nothing, removing it. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
* | | Merge pull request #3853 from donaldsharp/partial_revertDavid Lamparter2019-03-061-8/+8
|\ \ \ | | | | | | | | zebra: Prevent crash in dad auto recovery
| * | | zebra: Prevent crash in dad auto recoveryDonald Sharp2019-02-231-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit: 6005fe55bce1c9cd54f4f7773fc2b0e15a99008f Introduced a crash with zebra looking up either the nbr structure or the mac structure. This is because the zvni used is NULL and we eventually call a hash_lookup call that would cause a NULL dereference. Partially revert this commit to original behavior. Problems found via clang Static Analyzer. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | | Merge pull request #3869 from qlyoung/cocci-fixesDavid Lamparter2019-03-0610-49/+23
|\ \ \ \ | | | | | | | | | | Assorted Coccinelle fixes
| * | | | *: remove null check before XFREEQuentin Young2019-02-265-34/+17
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
| * | | | *: do not check XMALLOC / XCALLOC for null retQuentin Young2019-02-262-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They never return NULL Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
| * | | | *: remove unnecessary semicolon from switchesQuentin Young2019-02-262-3/+3
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
| * | | | *: remove useless return variablesQuentin Young2019-02-262-5/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
| * | | | *: return bool from boolean functionsQuentin Young2019-02-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not 1 or 0. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* | | | | zebra: When installing a new route always use REPLACEDonald Sharp2019-03-011-4/+3
| |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we install a new route into the kernel always use REPLACE. Else if the route is already there it can be translated into an append with the flags we are using. This is especially true for the way we handle pbr routes as that we are re-installing the same route entry from pbr at the moment. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | | Merge pull request #3882 from vivek-cumulus/refine_evpn_route_addSri Mohana Singamsetty2019-03-013-29/+15
|\ \ \ \ | | | | | | | | | | Refine install of EVPN-based routes to remove some special handling
| * | | | *: Explicitly mark nexthop of EVPN-sourced routes as onlinkvivek2019-02-272-17/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of EVPN symmetric routing, the tenant VRF is associated with a VNI that is used for routing and commonly referred to as the L3 VNI or VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP) interface (SVI). Overlay next hops (i.e., next hops for routes in the tenant VRF) are reachable over this interface. Howver, in the model that is supported in the implementation and commonly deployed, there is no explicit Overlay IP address associated with the next hop in the tenant VRF; the underlay IP is used if (since) the forwarding plane requires a next hop IP. Therefore, the next hop has to be explicit flagged as onlink to cause any next hop reachability checks in the forwarding plane to be skipped. https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement section 4.4 provides additional description of the above constructs. Use existing mechanism to specify the nexthops as onlink when installing these routes from bgpd to zebra and get rid of a special flag that was introduced for EVPN-sourced routes. Also, use the onlink flag during next hop validation in zebra and eliminate other special checks. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
| * | | | zebra, bgpd: Use L3 interface for VRF's VNI in route installvivek2019-02-271-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of EVPN symmetric routing, the tenant VRF is associated with a VNI that is used for routing and commonly referred to as the L3 VNI or VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP) interface (SVI). Overlay next hops (i.e., next hops for routes in the tenant VRF) are reachable over this interface. https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement section 4.4 provides additional description of the above constructs. Use the L3 interface exchanged between zebra and bgp in route install. This patch in conjunction with the earlier one helps to eliminate some special code in zebra to derive the next hop's interface. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
| * | | | zebra, bgpd: Exchange L3 interface for VRF's VNIvivek2019-02-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of EVPN symmetric routing, the tenant VRF is associated with a VNI that is used for routing and commonly referred to as the L3 VNI or VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP) interface (SVI). Overlay next hops (i.e., next hops for routes in the tenant VRF) are reachable over this interface. https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement section 4.4 provides additional description of the above constructs. The implementation currently derives this L3 interface for EVPN tenant routes using special code that looks at route flags. This patch exchanges the L3 interface between zebra and bgpd as part of the L3-VNI exchange in order to eliminate some this special code. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | | | | Merge pull request #3876 from qlyoung/fmt-fixesMark Stapp2019-02-281-5/+7
|\ \ \ \ \ | |_|_|_|/ |/| | | | style fixes...
| * | | | zebra: fix style for 7d9ee1Quentin Young2019-02-261-5/+7
| |/ / / | | | | | | | | | | | | Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* | | | Merge pull request #3800 from chiragshah6/evpn_devSri Mohana Singamsetty2019-02-271-0/+20
|\ \ \ \ | |/ / / |/| | | zebra: advertise evpn route upon l3vni svi mac chg
| * | | zebra: advertise evpn route upon l3vni svi mac chgChirag Shah2019-02-211-0/+20
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | L3VNI keeps reference to svi interface (ifp). When a netlink change received there is no flag that mac has changed. Currently simply overwrite interface's (ifp) hw_addr (MAC) field. For originating EVPN type-2 and type-5 routes due to VNI MAC change, comparison is required to check existing MAC vs. netlink change MAC field. Ticket:CM-23850 Reviewed By:CCR-8283 Testing Done: Validate EVPN type-5 routes originated upon changing MAC address of L3VNI's SVI inteface via ip link set cmd. checked show bgp l2vpn evpn route and Rmac field contains new MAC address. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
* | | Merge pull request #3865 from qlyoung/fix-zebra-vxlan-smelly-stringsRuss White2019-02-265-17/+16
|\ \ \ | |_|/ |/| | zebra: replace strncpy with strlcpy
| * | zebra: remove all instances of strncpyQuentin Young2019-02-255-17/+16
| | | | | | | | | | | | | | | | | | We have strlcpy. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* | | *: Rename backet to bucketTim Bray2019-02-254-124/+124
|/ / | | | | | | | | | | Presume typo from original author Signed-off-by: Tim Bray <tim@kooky.org>
* | zebra: Fix use after free in rib_process_resultDonald Sharp2019-02-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running zebra after commit 888756b208edc7935705d95b83f9513acc21e78a in valgrind produces this item: ==17102== Invalid read of size 8 ==17102== at 0x44D84C: rib_dest_from_rnode (rib.h:375) ==17102== by 0x4546ED: rib_process_result (zebra_rib.c:1904) ==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295) ==17102== by 0x4D0902B: thread_call (thread.c:1607) ==17102== by 0x4CC3983: frr_run (libfrr.c:1011) ==17102== by 0x4266F6: main (main.c:473) ==17102== Address 0x83bd468 is 88 bytes inside a block of size 96 free'd ==17102== at 0x4A35F54: free (vg_replace_malloc.c:530) ==17102== by 0x4CCAC00: qfree (memory.c:129) ==17102== by 0x4D03DC6: route_node_destroy (table.c:501) ==17102== by 0x4D039EE: route_node_free (table.c:90) ==17102== by 0x4D03971: route_node_delete (table.c:382) ==17102== by 0x44D82A: route_unlock_node (table.h:256) ==17102== by 0x454617: rib_process_result (zebra_rib.c:1882) ==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295) ==17102== by 0x4D0902B: thread_call (thread.c:1607) ==17102== by 0x4CC3983: frr_run (libfrr.c:1011) ==17102== by 0x4266F6: main (main.c:473) ==17102== Block was alloc'd at ==17102== at 0x4A36FF6: calloc (vg_replace_malloc.c:752) ==17102== by 0x4CCAA2D: qcalloc (memory.c:110) ==17102== by 0x4D03D88: route_node_create (table.c:489) ==17102== by 0x4D0360F: route_node_new (table.c:65) ==17102== by 0x4D034F8: route_node_set (table.c:74) ==17102== by 0x4D03486: route_node_get (table.c:327) ==17102== by 0x4CFB700: srcdest_rnode_get (srcdest_table.c:243) ==17102== by 0x4545C1: rib_process_result (zebra_rib.c:1872) ==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295) ==17102== by 0x4D0902B: thread_call (thread.c:1607) ==17102== by 0x4CC3983: frr_run (libfrr.c:1011) ==17102== by 0x4266F6: main (main.c:473) ==17102== This is happening because of this order of events: 1) Route is deleted in the main thread and scheduled for rib processing. 2) Rib garbage collection is run and we remove the route node since it is no longer needed. 3) Data plane returns from the deletion in the kernel and we call the srcdest_rnode_get function to get the prefix that was deleted. This recreates a new route node. This creates a route_node with a lock count of 1, which we freed via the route_unlock_node call. Then we continued to use the rn pointer. Which leaves us with use after frees. The solution is, of course, to just move the unlock the node at the end of the function if we have a route_node. Fixes: #3854 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | zebra: unlock route-node in dplane results handlerMark Stapp2019-02-211-0/+2
|/ | | | | | | Unlock the route-node struct we look up while processing async dataplane results. Signed-off-by: Mark Stapp <mjs@voltanet.io>
* Merge pull request #3791 from sworleys/RT-Braces-rtadvMark Stapp2019-02-141-4/+4
|\ | | | | zebra: Fix CLANG suggestion for braces on init of struct
| * zebra: Fix CLANG suggestion for braces on init of structStephen Worley2019-02-121-4/+4
| | | | | | | | | | | | | | CLANG was throwing an error because struct rtadv_rdnss(dnssl) was being initialized with = {0} instead of {}. Change to be the latter. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
* | zebra: Deletion of a lsp is not a failure eventDonald Sharp2019-02-131-3/+4
| | | | | | | | | | | | | | | | FRR is reporting that a lsp deletion event as a failure in the log messsages. This will lead to confusion and lots of fun debugging. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-06 04:37:34 +0100