Page MenuHomeFreeBSD

Align refcounting in multicast code between IPv4 and IPv6
ClosedPublic

Authored by hselasky on Nov 28 2019, 6:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 31 2024, 4:49 AM
Unknown Object (File)
Jan 11 2024, 11:04 PM
Unknown Object (File)
Dec 20 2023, 7:25 AM
Unknown Object (File)
Nov 22 2023, 5:11 PM
Unknown Object (File)
Nov 13 2023, 4:08 AM
Unknown Object (File)
Sep 13 2023, 3:34 AM
Unknown Object (File)
Aug 25 2023, 7:50 PM
Unknown Object (File)
Jul 30 2023, 10:08 PM

Details

Summary

Use refcount from "in_joingroup_locked()" when joining multicast groups. Do not acquire additional references.
This makes the IPv4 IGMP code in line with the IPv6 MLD code.

Background:
The IPv4 multicast code puts an extra reference on the in_multi struct when joining groups.
This becomes visible when using daemons like igmpproxy from ports, that multicast entries
do not disappear from the output of ifmcstat(8) when multicast streams are disconnected.

This fixes a regression issue after r349762.

Tested by: Guido van Rooij <guido@gvr.org>
MFC after: 1 week
Sponsored by: Mellanox Technologies

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 27905

Event Timeline

rgrimes added a subscriber: rgrimes.

Thanks for quickly addressing this. Just a code comment I noticed, and am curious if I missed something that would not allow the removal of a duplicate conditional

sys/netinet/in_mcast.c
2241–2242

Why restest is_new? Cant this line just be moved up to the last line of the prior if (is_new) right where the lock aquire was done before?

This revision is now accepted and ready to land.Dec 3 2019, 7:38 AM
sys/netinet/in_mcast.c
2241–2242

Then we would need to change the error out logic too, I.E. remove the entry upon failure. I think it is best to not insert the entry before everything is clear.

sys/netinet/in_mcast.c
2241–2242

I see your point. Let me re-order.

This revision now requires review to proceed.Dec 3 2019, 8:17 AM
This revision is now accepted and ready to land.Dec 3 2019, 8:30 AM