rev. 1.94 of netinet/in.c broke CARP

[Gleb Smirnoff]

On Thu, Jan 25, 2007 at 10:00:08PM +0000, Robert Watson wrote:
R> >On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote:
R> >R> Architecturally, the right fix is that CARP needs to have a handler for
R> >R> ifnet destruction that always runs before the multicast address garbage
R> >R> collection. I'm pretty preoccupied for the next few days due to an
R> >R> impending paper deadline, so can't investigate further currently, but 
R> >one
R> >R> way or the other that ordering dependency needs to be expressed.  If 
R> >done
R> >R> properly, CARP will always have released its multicast address before 
R> >they
R> >R> are forceably removed. Having the reference count is good too, but what 
R> >I
R> >R> describe should be sufficient regardless of the refcount.
R> >
R> >This means removing usage of EVENTHANDLER(9) and going back to exporting 
R> >carp_ifdetach() and calling it directly from if_detach(). This is back out 
R> >revision 1.255 of net/if.c. Not sure what is a right way...
R> >
R> >I am worried about that CARP is not the only subsystem in kernel that can 
R> >join a multicast group on an ifnet, and keep a pointer to the multicast 
R> >instance.
R> 
R> Alternatively, we move to having two event handlers: one for general stack 
R> consumers to use, and a second one to do low level address and protocol 
R> cleanup.  CARP would use the former, multicast address stuff the latter...

Well, I am just not sure that the new coding strategy, chosen by Bruce is
correct. We used to have every subsystem to join multicast membership itself,
and leave it itself. Due to bugs in the Ethernet layer (?) on interface
detach some multicast memberships were not left and thus memory was leaking.

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?

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?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE