From owner-freebsd-net@freebsd.org Fri Jul 7 14:49:11 2017 Return-Path: Delivered-To: freebsd-net@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 EA417DA4D8B for ; Fri, 7 Jul 2017 14:49:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2o.cmail.yandex.net (forward2o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::287]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89F877CB45; Fri, 7 Jul 2017 14:49:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::28]) by forward2o.cmail.yandex.net (Yandex) with ESMTP id 29ABB21186; Fri, 7 Jul 2017 17:49:07 +0300 (MSK) Received: from smtp4o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp4o.mail.yandex.net (Yandex) with ESMTP id F03F46C008C0; Fri, 7 Jul 2017 17:49:04 +0300 (MSK) Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id aUXjwbCj0Q-n3n429Qd; Fri, 07 Jul 2017 17:49:03 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1499438943; bh=mDRdXWgRHX1bIRSb4ZHhE6o+ZrtlOnBmySRwAkZPRdo=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=kMI/zb+enGaB7HdEUWiUnJ98Bo4+2RmUrrhRXVSwRKp6hcRvdTU/xvtP+q2L3J5j5 mG6RfQxS3OT4S2f/p1eI0ENylEVd2xIMOjYzmQ0p+uGo1+Bo/Qt/JBdErhCOpllxTP nFEL2g7ifZEJIP/ivTKnvbI4U9I3PscGQVZ3jNWA= Authentication-Results: smtp4o.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 0 Subject: Re: m_move_pkthdr leaves m_nextpkt 'dangling' To: Adrian Chadd , Karim Fodil-Lemelin Cc: FreeBSD Net , Gleb Smirnoff References: <59567148.1020902@xiplink.com> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <31535133-f95a-5db6-a04c-acc0175fa287@yandex.ru> Date: Fri, 7 Jul 2017 17:46:39 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kq9FClqC02i4JQKr81nFaqfiAEbJgprfb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:49:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kq9FClqC02i4JQKr81nFaqfiAEbJgprfb Content-Type: multipart/mixed; boundary="UCeCAcPu8bPqcLXC4DbbO7b8n2MgrWxVw"; protected-headers="v1" From: "Andrey V. Elsukov" To: Adrian Chadd , Karim Fodil-Lemelin Cc: FreeBSD Net , Gleb Smirnoff Message-ID: <31535133-f95a-5db6-a04c-acc0175fa287@yandex.ru> Subject: Re: m_move_pkthdr leaves m_nextpkt 'dangling' References: <59567148.1020902@xiplink.com> In-Reply-To: --UCeCAcPu8bPqcLXC4DbbO7b8n2MgrWxVw Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05.07.2017 19:23, Adrian Chadd wrote: >> As many of you know, when dealing with IP fragments the kernel will bu= ild a >> list of packets (fragments) chained together through the m_nextpkt poi= nter. >> This is all good until someone tries to do a M_PREPEND on one of the p= acket >> in the chain and the M_PREPEND has to create an extra mbuf to prepend = at the >> beginning of the chain. >> >> When doing so m_move_pkthdr is called to copy the current PKTHDR field= s >> (tags and flags) to the mbuf that was prepended. The function also doe= s: >> >> to->m_pkthdr =3D from->m_pkthdr; >> >> This, for the case I am interested in, essentially leaves the 'from' m= buf >> with a dangling pointer m_nextpkt pointing to the next fragment. While= this >> is mostly harmless because only mbufs of pkthdr types are supposed to = have >> m_nextpkt it triggers some panics when running with INVARIANTS in NetG= raph >> (see ng_base.c :: CHECK_DATA_MBUF(m)): >> >> ... >> if (n->m_nextpkt !=3D NULL) = \ >> panic("%s: m_nextpkt", __func__); = \ >> } >> ... >> >> So I would like to propose the following patch: >> >> @@ -442,10 +442,11 @@ m_move_pkthdr(struct mbuf *to, struct mbuf *from= ) >> if ((to->m_flags & M_EXT) =3D=3D 0) >> to->m_data =3D to->m_pktdat; >> to->m_pkthdr =3D from->m_pkthdr; /* especially tags *= / >> SLIST_INIT(&from->m_pkthdr.tags); /* purge tags from src= */ >> from->m_flags &=3D ~M_PKTHDR; >> + from->m_nextpkt =3D NULL; >> } >> >> It will reset the m_nextpkt so we don't have two mbufs pointing to the= same >> next packet. This is fairly harmless and solves a problem for us here = at >> XipLink. >=20 > This seems like a no-brainer. :-) Any objections? I think the change is reasonable. But from other side m_demote_pkthdr() may also need this change. Maybe we can wait when Gleb will be back and review this? Also he is the author of the mentioned assertion in netgraph code. --=20 WBR, Andrey V. Elsukov --UCeCAcPu8bPqcLXC4DbbO7b8n2MgrWxVw-- --Kq9FClqC02i4JQKr81nFaqfiAEbJgprfb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAllfns8ACgkQAcXqBBDI oXq01Af/UPqo0Bxyqb4m+GN1rlS9ML7e2J9n4eQGiLnwdAz8lBn1MK/6Chrr4eJg lHAEu4+dzzCl1a+rWnkaHtG5ONfpHL1ZDijYo0y4DcsHZTUMQSOCV89V1ZJwjs40 Ik/Kp+eoUp5INyr4b5t8NAaL62jqSvYc2HZI2Y8h3s/3toQ6wi865CnrL8Lu02y1 NtX7/ig9uQN2nr4SZwKT8eOr3dBbdqiu6Nuca9MJJsKToFEbgeiobxMraaXjF1RS wxa5YO80T0sGnWdT30s/jsMfQ2c2H/lYxCNxSKzmu+E1S0PWG1R7zia8b/BNY/XX NIDa3VA9tRiraI2CerROnl7cwMhhwA== =Cc77 -----END PGP SIGNATURE----- --Kq9FClqC02i4JQKr81nFaqfiAEbJgprfb--