Re: rev. 1.94 of netinet/in.c broke CARP

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: rev. 1.94 of netinet/in.c broke CARP
    ... the right fix is that CARP needs to have a handler for ... R> ifnet destruction that always runs before the multicast address garbage ... CARP will always have released its multicast address before they ...
    (freebsd-net)
  • Re: rev. 1.94 of netinet/in.c broke CARP
    ... 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. ... Unfortunately, due to how CARP works, two bugs were fixed at the expense of introducing another. ... Call multicast cleanup, if we are destroying carp interface itself. ... 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, ...
    (freebsd-net)
  • rev. 1.94 of netinet/in.c broke CARP
    ... that revision 1.94 of in.c has broke CARP. ... of all multicast instances and deletes all the instances, ... ifconfig vlan0 destroy ...
    (freebsd-net)
  • Re: rev. 1.94 of netinet/in.c broke CARP
    ... the right fix is that CARP needs to have a handler for ... R> ifnet destruction that always runs before the multicast address garbage ... CARP will always have released its multicast address before they ...
    (freebsd-net)
  • Re: rev. 1.94 of netinet/in.c broke CARP
    ... the right fix is that CARP needs to have a handler ... for R> ifnet destruction that always runs before the multicast address ... its multicast address before they R> are forceably removed. ...
    (freebsd-net)