rev. 1.94 of netinet/in.c broke CARP
Bruce M. Simpson
bms at FreeBSD.org
Mon Jan 29 22:59:07 UTC 2007
I've had a chance to read ip_carp.c in more detail now, so...
Gleb Smirnoff wrote:
> Is adding a generic GC function a correct way or was it better to just fix
> the buggy layer, that forgot about its multicast memberships?
In the bigger picture: The real fix for netinet is to do what netinet6
does; that is, refcount the memberships and keep them in a list, rather
than a vector. This would have been my preferred fix. However, this
breaks the ABI for drivers, and is a larger change.
The less intrusive, non-ABI-breaking change (discussed with Robert at
the time) was to convert a statically allocated array to a
This was considered acceptable for the upcoming 6.2 release at that
point in time. Unfortunately, due to how CARP works, two bugs were fixed
at the expense of introducing another.
> ATM, I can fix the CARP in the following way:
> 1) Call multicast cleanup, if we are destroying carp interface itself.
> 2) Don't call multicast cleanup, if we are called through EVENTHANDLER(9)
> since parent is detaching.
> Would this fix be ok?
Yes. In fact I would go so far as to say that it is the correct
behaviour for CARP.
Resource allocation and free for CARP runs along two separate paths; the
case where a member interface is detached cannot be considered the same
as when CARP itself is detaching, they are two distinct paths.
imo_membership 'belongs to' netinet attached to an ifnet. CARP merely
More information about the freebsd-net