From owner-svn-src-head@FreeBSD.ORG Thu Mar 13 03:14:28 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DD5711B; Thu, 13 Mar 2014 03:14:28 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE27F9ED; Thu, 13 Mar 2014 03:14:26 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.8/8.14.8) with ESMTP id s2D3E3nI039217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Mar 2014 07:14:03 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.8/8.14.8/Submit) id s2D3E391039216; Thu, 13 Mar 2014 07:14:03 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 13 Mar 2014 07:14:03 +0400 From: Gleb Smirnoff To: Andrey Chernov Subject: Re: svn commit: r263091 - in head/sys: netinet netinet6 Message-ID: <20140313031403.GQ80022@FreeBSD.org> References: <201403121429.s2CET8Hh038762@svn.freebsd.org> <5320CCFB.7090301@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5320CCFB.7090301@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 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, 13 Mar 2014 03:14:28 -0000 On Thu, Mar 13, 2014 at 01:09:15AM +0400, Andrey Chernov wrote: A> On 12.03.2014 18:29, Gleb Smirnoff wrote: A> > --- head/sys/netinet/ip_input.c Wed Mar 12 12:27:13 2014 (r263090) A> > +++ head/sys/netinet/ip_input.c Wed Mar 12 14:29:08 2014 (r263091) A> > @@ -794,6 +795,8 @@ SYSCTL_PROC(_net_inet_ip, OID_AUTO, maxf A> > NULL, 0, sysctl_maxnipq, "I", A> > "Maximum number of IPv4 fragment reassembly queue entries"); A> > A> > +#define M_IP_FRAG M_PROTO9 A> > + A> > /* A> > * Take incoming datagram fragment and try to reassemble it into A> > * whole datagram. If the argument is the first fragment or one A> > A> > Modified: head/sys/netinet6/in6.h A> > ============================================================================== A> > --- head/sys/netinet6/in6.h Wed Mar 12 12:27:13 2014 (r263090) A> > +++ head/sys/netinet6/in6.h Wed Mar 12 14:29:08 2014 (r263091) A> > @@ -622,13 +622,18 @@ struct ip6_mtuinfo { A> > #endif /* __BSD_VISIBLE */ A> > A> > /* A> > - * Redefinition of mbuf flags A> > + * Since both netinet/ and netinet6/ call into netipsec/ and netpfil/, A> > + * the protocol specific mbuf flags are shared between them. A> > */ A> > -#define M_AUTHIPHDR M_PROTO2 A> > -#define M_DECRYPTED M_PROTO3 A> > -#define M_LOOP M_PROTO4 A> > -#define M_AUTHIPDGM M_PROTO5 A> > -#define M_RTALERT_MLD M_PROTO6 A> > +#define M_FASTFWD_OURS M_PROTO1 /* changed dst to local */ A> > +#define M_IP6_NEXTHOP M_PROTO2 /* explicit ip nexthop */ A> > +#define M_IP_NEXTHOP M_PROTO2 /* explicit ip nexthop */ A> > +#define M_SKIP_FIREWALL M_PROTO3 /* skip firewall processing */ A> > +#define M_AUTHIPHDR M_PROTO4 A> > +#define M_DECRYPTED M_PROTO5 A> > +#define M_LOOP M_PROTO6 A> > +#define M_AUTHIPDGM M_PROTO7 A> > +#define M_RTALERT_MLD M_PROTO8 A> > A> A> Next time someone add new mbuf flag to in6.h, it will be M_PROTO9 and A> situation repeat itself, since you left M_PROTO9 in ip_input.c Not true probably. The ip fragment reassembly code is dead end of the stack. Once mbufs reach the reassembly queue, they won't go anywhere else. So clash there should be safe. Notice that before my commit M_IP_FRAG was clashing with M_LOOP and we didn't have any bug reports on that. I've put the non-clashing value there just being overcautios and not having enough time to analyze and test the reassembly. I also put an XXX comment, it seems to me that resulting (reassembled mbuf) might inherit flags from the first fragment, and I am not absolutely sure it is correct. -- Totus tuus, Glebius.