From owner-svn-src-head@FreeBSD.ORG Thu Oct 30 11:34:30 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 814715C2 for ; Thu, 30 Oct 2014 11:34:30 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D1F5D29 for ; Thu, 30 Oct 2014 11:34:30 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 64815207BC for ; Thu, 30 Oct 2014 07:34:29 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Thu, 30 Oct 2014 07:34:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h= message-id:x-sasl-enc:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=mesmtp; bh=4mb//SXTalTR6gapDaNTy3invFo=; b=PM6z 2vjlcvnGDdsV2rbQk0il56LRhFVYVsZIQoNAKsR6TULSReAg8Cw0VDlpYUxGqOXj SmouV8cs42qPYrhmgZKnJ+1PTKMHdcHMqay6+XBiDf/XTYJHGxG41/OoI49BCQYl nM7Bb77U4CT+VYxuPFdnB7r+XxaGG56fplbyWOs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=4mb//SXTalTR6gapDaNTy3in vFo=; b=oavS6+VeDdacSqhFMXssz1tVFMUSlPSify2+dnCEmmDlM2Ghg1aGsBrl WngJuMa9XEM75h+l6K20Hxi6TVzxcKpC0MQ8wgA3L/JR2Ln9G/DOrdGz/nVHS/3f MNikkzN4v7FNZUhHeH4mwBprWbPYWT6WACy5huNh02yHyCH9f/0= Received: by web6.nyi.internal (Postfix, from userid 99) id 3A62B59472; Thu, 30 Oct 2014 07:34:29 -0400 (EDT) Message-Id: <1414668869.979804.185070381.0D4C866C@webmail.messagingengine.com> X-Sasl-Enc: ZcL4GH+JsAMCish7GYR5qss3M3f4+c0xtrjG4kqeQCO5 1414668869 From: Bruce Simpson To: "Andrey V. Elsukov" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-c51dec4f In-Reply-To: <201410301059.s9UAxwAg055812@svn.freebsd.org> References: <201410301059.s9UAxwAg055812@svn.freebsd.org> Subject: Re: svn commit: r273855 - head/sys/netinet6 Date: Thu, 30 Oct 2014 11:34:29 +0000 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:34:30 -0000 Hello, This is a really inconvenient time for me (I am up against a deadline) but I am not 100% comfortable with this change. On Thu, 30 Oct 2014, at 10:59, Andrey V. Elsukov wrote: > Log: > Fix mbuf leak in IPv6 multicast code. > When multicast capable interface goes away, it leaves multicast groups, > this leads to generate MLD reports, but MLD code does deffered send and > MLD reports are queued in the in6_multi's in6m_scq ifq. The problem is > that in6_multi structures are freed when interface leaves multicast > groups > and thread that does deffered send will not take these queued packets. A few comments: 1) Stylistic -- a change of this kind should probably be part of inm_purge() itself because it modifies state which is private to the group membership. 2) Logical -- The patch forces pending (queued) state change record fragments to be freed when the parent interface is taken down. Unfortunately, those are pending for a reason; there has been a state change, and MLD needs to communicate it upstream to on-link routers (and snooping switches). So - there is a risk with this approach that upstream MLD listener (e.g. router, switch) will be inconsistent, at least until the next General Query. A better approach might be to force an INCLUDE {} to be sent for the group (there are other parts of the code which try to do this for similar events), but if the parent interface has already been taken down, all bets are off. As of writing - The FreeBSD networking stack doesn't provide any hints either way about the nature of the teardown. Perhaps need to be a distinction between use cases where a hasty teardown is unlikely to have operational impact (e.g. an ephemeral VPN session between two nodes which is point-to-point in nature, and not generally used for forwarding traffic), and cases where it may impact other users (e.g. an MLD membership residing on a wireless interface, which might result in unwanted multicast traffic being relayed to an 802.11 ESS). -- BMS (sent via webmail)