rev. 1.94 of netinet/in.c broke CARP

[Bruce M. Simpson]

Hello,

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 
lazy-reallocated vector.

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 
borrows it.

Regards,
BMS