From owner-svn-src-stable@freebsd.org Tue Dec 8 07:47:02 2015 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B2869D326A; Tue, 8 Dec 2015 07:47:02 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (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 2FFAC128B; Tue, 8 Dec 2015 07:47:02 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id tB87l1NI079487; Tue, 8 Dec 2015 07:47:01 GMT (envelope-from ae@FreeBSD.org) Received: (from ae@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id tB87l1qR079486; Tue, 8 Dec 2015 07:47:01 GMT (envelope-from ae@FreeBSD.org) Message-Id: <201512080747.tB87l1qR079486@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ae set sender to ae@FreeBSD.org using -f From: "Andrey V. Elsukov" Date: Tue, 8 Dec 2015 07:47:01 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-9@freebsd.org Subject: svn commit: r291991 - stable/9/sys/netinet X-SVN-Group: stable-9 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 07:47:02 -0000 Author: ae Date: Tue Dec 8 07:47:01 2015 New Revision: 291991 URL: https://svnweb.freebsd.org/changeset/base/291991 Log: MFC r291579: In the same way fix the problem described in r291578 for IGMPv3. In case when router has a lot of multicast groups, the reply can take several packets due to MTU limitation. Also we have a limit IGMP_MAX_RESPONSE_BURST == 4, that limits the number of packets we send in one shot. Then we recalculate the timer value and schedule the remaining packets for sending. The problem is that when we call igmp_v3_dispatch_general_query() to send remaining packets, we queue new reply in the same mbuf queue. And when number of packets is bigger than IGMP_MAX_RESPONSE_BURST, we get endless reply of IGMPv3 reports. To fix this, add the check for remaining packets in the queue. Modified: stable/9/sys/netinet/igmp.c Directory Properties: stable/9/sys/ (props changed) Modified: stable/9/sys/netinet/igmp.c ============================================================================== --- stable/9/sys/netinet/igmp.c Tue Dec 8 07:43:12 2015 (r291990) +++ stable/9/sys/netinet/igmp.c Tue Dec 8 07:47:01 2015 (r291991) @@ -3326,6 +3326,15 @@ igmp_v3_dispatch_general_query(struct ig KASSERT(igi->igi_version == IGMP_VERSION_3, ("%s: called when version %d", __func__, igi->igi_version)); + /* + * Check that there are some packets queued. If so, send them first. + * For large number of groups the reply to general query can take + * many packets, we should finish sending them before starting of + * queuing the new reply. + */ + if (igi->igi_gq.ifq_head != NULL) + goto send; + ifp = igi->igi_ifp; IF_ADDR_RLOCK(ifp); @@ -3361,6 +3370,7 @@ igmp_v3_dispatch_general_query(struct ig } IF_ADDR_RUNLOCK(ifp); +send: loop = (igi->igi_flags & IGIF_LOOPBACK) ? 1 : 0; igmp_dispatch_queue(&igi->igi_gq, IGMP_MAX_RESPONSE_BURST, loop);