From: David Ahern <d...@cumulusnetworks.com> Date: Tue, 24 Jan 2017 18:35:02 -0700
> On 1/23/17 9:51 AM, David Ahern wrote: >> On 1/22/17 9:58 PM, David Miller wrote: >>> David, please slow down. >>> >>> How is the NULL entry getting selected to be dumped and passed >>> down here in the first place? >> The null_entry might be a 'marker' but is integral to the ipv6 fib. > > As I mentioned in my last response the null_entry is tb6_root.leaf for all > tables making it part of the table. Since the dump walks the table and sends > each route to rt6_dump_route, the dump includes the null_entry. > > ip6_null_entry->rt6i_idev is NULL because ip6_route_net_init is run before > addrconf_init has initialized the loopback device. > > Given that, it seems like a check is needed somewhere ... be it 'rt == > net->ipv6.ip6_null_entry' in rt6_dump_route or fib6_dump_node, or a check for > rt6i_idev NULL in rt6_fill_node. > > You marked the last patch as changes needed meaning another needs to be sent. > > Suggestion? Probably putting the check as high in the call chain as possible, via fib6_dump_node(), is the best. Although, it's troubling that we are trying to dump unfinished entries simply because of initialization order. It's arguable that this is the real thing to fix. The loopback device is a hard dependency which the ipv6 stack has because of how it does statistics and other things.
