Page MenuHomeFreeBSD

Fix panic induced by ndp -P
Needs ReviewPublic

Authored by rstone on Jun 17 2020, 6:24 PM.

Details

Reviewers
bz
markj
ae
melifaro
Group Reviewers
network
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

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 31777
Build 29339: arc lint + arc unit

Event Timeline

rstone created this revision.Jun 17 2020, 6:24 PM
rstone requested review of this revision.Jun 17 2020, 6:24 PM
markj added a comment.Jun 18 2020, 2:27 PM

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.

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?