Fix panic induced by ndp -P

[rstone]

Summary

If ndp -P was run, the kernel attempted to free all NDP prefixes,
even those for statically assigned IPs. Instead track the number
of autoconf addresses associated with each prefix and only have
ndp -P flush prefixes exclusively associated with autoconf
addresses.

Submitted by: Sabiha Tamragouri
Sponsored by: Dell EMC Isilon
MFC after: 1 month

[markj]

We should update the ndp man page to clarify which prefixes are being freed.

nd6_prefix_del() should assert that the autoconf address count is zero.

sys/netinet6/nd6.c

1786

Style, the || should be on the previous line.

So we don't purge any addresses if a non-autoconf address belongs to the prefix, but isn't that kind of surprising behaviour? I thought the main purpose of ndp -P is to flush all autoconfigured addresses.

sys/netinet6/nd6.h

240

Call it ndpr_autoconf_addrcnt, to be more consistent with ndpr_addrcnt?

sys/netinet6/nd6_rtr.c

2384

The if-statement condition is always true here.

[melifaro]

Any chance a test can be added to verify the desired behaviour? IT shouldn't be too hard, there are multiple examples of tests creating 2 vnet jails for the simular purposes in netinet6/.

sys/netinet6/nd6.c

1786

In the other places, ndpr_num_autoconf_addrs was incremented/decremented w/o holding any lock.

Maybe, doing per-prefix wlock on increment/decrement and checking the condition under wlock here as well could work.

Also, a very dumb question: how does it help preventing panic?

sys/netinet6/nd6_rtr.c

1352

Is this needed given M_ZERO above?