From owner-freebsd-net@FreeBSD.ORG Thu Jan 25 18:24:36 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DB7016A400; Thu, 25 Jan 2007 18:24:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5B213C468; Thu, 25 Jan 2007 18:24:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id BEC0E9763D; Thu, 25 Jan 2007 12:38:45 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Thu, 25 Jan 2007 12:38:45 -0500 X-Sasl-enc: j2+PKSGr0AEGO+mGlFuxncAxg1X3jNFh7D5V17V/zUxU 1169746725 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 300F3151A0; Thu, 25 Jan 2007 12:38:44 -0500 (EST) Message-ID: <45B8EB23.705@FreeBSD.org> Date: Thu, 25 Jan 2007 17:38:43 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Gleb Smirnoff References: <20070125162422.GA7922@bestcom.ru> In-Reply-To: <20070125162422.GA7922@bestcom.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: rev. 1.94 of netinet/in.c broke CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 18:24:36 -0000 Gleb, Good catch, thanks for tracking this down. Gleb Smirnoff wrote: > I've just discovered, that revision 1.94 of in.c has broke CARP. This > change adds a code to in_ifdetach() that goes through the global list > of all multicast instances and deletes all the instances, that are > belonging to a particular interface. This is intended to avoid leaking > multicast instances. > The irony of this of course is that I was working on two separate fixes; one to prevent the MROUTING code panicking when an interface was suddenly removed, and the other to prevent the netinet ifp detach path from panicking in the same circumstances. These are resource leaks which have been in BSD for years and years. I neglected to test them *together* however; carp(4) was being used in the test cases for both bugs. > Before this change, most of the subsystems, that allocated multicast > membership instances had freed is theirselves. I don't know about others, > but at least CARP is broken now. It attempts to free a memory, that > already has been freed. > I would suggest that the correct fix, for now, would be for carp(4) to now *not* perform its own cleanup for the IPv4 groups it joins on member interfaces. The symptom here is that carp(4) needs to join a multicast group on its member interface. When the interface goes away, the group membership is now destroyed, at the netinet global level, by the netinet detach path first. However, carp(4) is keeping its own imo_membership vector of the addresses it joined on its member interfaces (rather than using the one which netinet assigns to it in its attach path), and later tries to free these memberships. netinet6 does not have the same problem because in6 memberships are reference counted. The root problem is that we should be using consistent semantics for both the IPv4 and IPv6 paths, and the kernel APIs where soft-ifnets (such as carp(4)) and routing code (such as MROUTING) need to manipulate multicast group memberships. Regards, BMS