Date: Thu, 30 Oct 2014 11:34:29 +0000 From: Bruce Simpson <bms@fastmail.net> To: "Andrey V. Elsukov" <ae@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r273855 - head/sys/netinet6 Message-ID: <1414668869.979804.185070381.0D4C866C@webmail.messagingengine.com> In-Reply-To: <201410301059.s9UAxwAg055812@svn.freebsd.org> References: <201410301059.s9UAxwAg055812@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1414668869.979804.185070381.0D4C866C>