Page MenuHomeFreeBSD

Always start IPv6 DAD asynchronously
ClosedPublic

Authored by markj on May 30 2016, 2:41 AM.
Tags
None
Referenced Files
Unknown Object (File)
Nov 14 2024, 8:02 PM
Unknown Object (File)
Nov 14 2024, 8:01 PM
Unknown Object (File)
Nov 1 2024, 3:30 AM
Unknown Object (File)
Sep 30 2024, 8:21 AM
Unknown Object (File)
Sep 25 2024, 1:17 PM
Unknown Object (File)
Sep 25 2024, 1:17 PM
Unknown Object (File)
Sep 25 2024, 1:17 PM
Unknown Object (File)
Sep 25 2024, 1:04 PM
Subscribers

Details

Summary

Currently, when nd6_dad_start() is called with a delay of 0 we send a
NS in the context of the caller. The places restrictions on the locks
the caller is allowed to hold. However, there's no good reason to
transmit the NS synchronously, so allow the first NS to always be
transmitted by the callout: the latent transmission doesn't matter
for the purposes of DAD. When nd6_dad_start() is called with a delay
of 0, we pass a "ticks" value of 0 to callout_reset(9), which schedules
the callout for the next tick.

Exploit the new behaviour to fix the IPv6 address list locking in
pfxlist_onlink_check().

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj retitled this revision from to Always start IPv6 DAD asynchronously.
markj edited the test plan for this revision. (Show Details)
markj updated this object.

Hi, any objection to this change? I know that there was a proposal for a more general mechanism that allows for asynchronous dispatch of control packets, but this is simpler and makes DAD more consistent, since we now always send the NS from the callout handler.

hrs edited edge metadata.

Sorry for the delay. Looks good to me.

This revision is now accepted and ready to land.Jun 1 2016, 5:03 AM
ae edited edge metadata.

I have no objections against this.

This revision was automatically updated to reflect the committed changes.