From owner-freebsd-net@FreeBSD.ORG Tue Jul 18 19:03:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5424316A4DE for ; Tue, 18 Jul 2006 19:03:23 +0000 (UTC) (envelope-from wiresncode@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA21143D6B for ; Tue, 18 Jul 2006 19:03:21 +0000 (GMT) (envelope-from wiresncode@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so110545wri for ; Tue, 18 Jul 2006 12:03:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Svry7NnAjfmq9JdEQdaB9iGvdtSr3UN/9LAg3yPmKIb02zxdAe/aYhgcQimS51Sc1/fKjlehzbNOk+RskJrm7g7/BVsw95NGbOrGnttfejgWn6je9YfLa+UU8S/7S/nuhS+O/HsUnLQo6mWpeQe+b11PEBQM3/n46FnBK6yz+dM= Received: by 10.65.219.3 with SMTP id w3mr1156800qbq; Tue, 18 Jul 2006 12:03:20 -0700 (PDT) Received: by 10.64.21.10 with HTTP; Tue, 18 Jul 2006 12:03:20 -0700 (PDT) Message-ID: <9050f13e0607181203r610da712kc506507b4f90b77c@mail.gmail.com> Date: Tue, 18 Jul 2006 12:03:20 -0700 From: "Tom Parker" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Possible inconsistency in the use of in6_delmulti() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tom@wiresncode.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 19:03:23 -0000 Hi, New to the list here, but fairly familiar with the innards of (at least an older) version of the fbsd networking code. I'm fortunate in my ability to run purify on a simulated instance of our ported version of the networking code. Purify has picked up a problem that I'm a bit mystified as how it can be fixed. It is present in current versions also, I'm interested in any comments people have (I think ours is 4.4 vintage, but it is hard to tell). As far as I can tell, in most calling paths when in6_delmulti() is called, it is done after the in6_multi_mship structure has been removed from the im6o_memberships list in the relevant PCB. This applies to in6_ifdetach(), in6_pcbpurgeif0, ip6_setmoptions() etc. However in in6_purgeaddr() in6_delmulti is called straight off. I'm not sure if we've violated some usage convention, but purify is telling me this causes access violations when we then leave the same group using setsockopt(). in6_purgeaddr is called when we remove the address from the interface. This should be possible in a real kernel. Add a multicast address to an interface, open a socket and listen to the address, then remove the address from the interface. Am I missing something here or is this a nasty problem in both the kernel and our stack port? Thanks, Tom ================= Tom Parker tom@wiresncode.com