On Fri, 1 Apr 2016 08:23:34 -0400
Donald Sharp <sha...@cumulusnetworks.com> wrote:

> My understanding -
> 
> Paul and I are working through a bunch of issues in the background.
> I'm slammed getting a new release out so am pretty busy right now.
> The take-3 branch has been rebased to the latest release already.
> Paul was going to take a schwag at fixing up a couple of the issues
> he had with the branch( Is my memory correct here Paul? )
> 
> I believe the nhrp code has already been rebased ontop of the take-3
> branch as well.

I was looking at the just now reported multipath issue. And while
debugging that I noticed that the take-3 branch next hop tracking
probably has some issues.

Running it under valgrind reports (with the simple test case of two
static routes; same prefix, different nexthop):

==5157== Conditional jump or move depends on uninitialised value(s)
==5157==    at 0x52BE36D: family2afi (prefix.c:217)
==5157==    by 0x131AC3: zebra_lookup_rnh (zebra_rnh.c:119)
==5157==    by 0x131E17: zebra_deregister_rnh_static_nh (zebra_rnh.c:208)
==5157==    by 0x131C50: zebra_deregister_rnh_static_nexthops (zebra_rnh.c:239)
==5157==    by 0x11F609: rib_unlink (zebra_rib.c:1857)
==5157==    by 0x11F609: rib_process (zebra_rib.c:1514)
==5157==    by 0x11F609: process_subq (zebra_rib.c:1541)
==5157==    by 0x11F609: meta_queue_process (zebra_rib.c:1582)
==5157==    by 0x52D5EF1: work_queue_run (workqueue.c:304)
==5157==    by 0x52C067A: thread_call (thread.c:1266)
==5157==    by 0x114F75: main (main.c:485)

==5157== Use of uninitialised value of size 8
==5157==    at 0x131AC6: zebra_lookup_rnh (zebra_rnh.c:119)
==5157==    by 0x131E17: zebra_deregister_rnh_static_nh (zebra_rnh.c:208)
==5157==    by 0x131C50: zebra_deregister_rnh_static_nexthops (zebra_rnh.c:239)
==5157==    by 0x11F609: rib_unlink (zebra_rib.c:1857)
==5157==    by 0x11F609: rib_process (zebra_rib.c:1514)
==5157==    by 0x11F609: process_subq (zebra_rib.c:1541)
==5157==    by 0x11F609: meta_queue_process (zebra_rib.c:1582)
==5157==    by 0x52D5EF1: work_queue_run (workqueue.c:304)
==5157==    by 0x52C067A: thread_call (thread.c:1266)
==5157==    by 0x114F75: main (main.c:485)

Also to me the some of the changes to RIB_ENTRY_NEXTHOPS_CHANGED
handling in the rib_process() look redundant. And probably not worth
adding.

E.g. the flag checking before calling nexthop_active_update(rn,rib,0)
is unneeded because the flag is reset in the beginning of the loop.

Cheers,
Timo


Cheers,
Timo


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to