svn commit: r273855 - head/sys/netinet6

Adrian Chadd adrian at freebsd.org
Thu Oct 30 16:06:01 UTC 2014


Btw - this is also a problem in the wifi stack. When you destroy an
interface, do you want to make sure the STA "going away" frames go out
and are ACKed before you finish tearing down the interface? We don't
really have any framework / standards in place for how to put tearing
down an interface on hold whilst we notify things and wait for packets
to finish transmitting, so we don't bother.

(I had the same issue with net80211 / ath and transmit buffers hanging
around after I destroyed a VAP. They came from the "disassociate"
packet being generated when the interface was being torn down.)



-adrian


On 30 October 2014 07:43, Andrey V. Elsukov <ae at freebsd.org> wrote:
> On 30.10.2014 14:34, Bruce Simpson wrote:
>> 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.
>
> I'm not quite sure, but I think that the leak happened only when
> interface disappeared. In case when system just leaves the group, MLD
> code takes reference to in6_multi and releases it when fasttimo handler
> dispatches packets. When interface is disappearing, in6_ifdetach() calls
> in6_purgemaddrs(), where all references to in6_multi released again. Now
> in6m_release_locked() will drain queue when in6_multi has no more
> references.
>
> --
> WBR, Andrey V. Elsukov
>


More information about the svn-src-all mailing list