Pin that a rebind survives repeated interface recreations - #73
Merged
Conversation
A destroyed interface's memberships are not scrubbed from a surviving socket, so re-joining on a kept fd adds one per recreation and stops working at igmp_max_memberships -- 20 by default, measured. Reopening the join fd is what avoids that, and nothing pinned it. The test joins a group and runs 25 recreate/rebind cycles; with the reopen removed it fails at the 20th membership with ENOBUFS.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The rebind reopens its multicast-join fd rather than re-joining on the existing
one. The comment justified that partly by a claim I had not measured: that
memberships for a destroyed interface keep counting against the socket's cap.
Measured it. With
igmp_max_membershipsat its default 20, joining one group onone kept socket across successive interface recreations succeeds exactly 20 times
and then fails with
ENOBUFS— so a destroyed interface's memberships really arenot scrubbed from a surviving socket, and a kept join fd would leave the daemon
permanently unable to join anything after 20 recreations.
That is a stronger reason for the reopen than the duplicate-join refusal, and
nothing pinned it, so this adds the test that does: join a group, then 25
recreate/reidentify/rebind cycles, asserting each rebind succeeds and the socket
still reports its groups joined.
It pins our behaviour rather than the kernel's, deliberately. If a future kernel
starts scrubbing, the test simply passes; if someone decides the reopen looks
wasteful, it fails. Verified it catches that: with the reopen reverted to a
re-join in place it fails at recreation 19 — the initial join plus 19 more being
the cap — with the ENOBUFS in the log.
The comment now cites the measurement and points at the test instead of arguing
the case, which made it shorter.
910 unit tests native (Debug, ASan/UBSan), 899 in docker including 21 root-gated.