From owner-svn-src-all@FreeBSD.ORG Tue Nov 25 14:15:07 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A46D7ADE; Tue, 25 Nov 2014 14:15:07 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 629F5FFD; Tue, 25 Nov 2014 14:15:07 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 87B2BA0B7; Tue, 25 Nov 2014 14:15:06 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 0554B12C3; Tue, 25 Nov 2014 15:14:56 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ermal =?utf-8?Q?Lu=C3=A7i?= Subject: Re: svn commit: r274709 - head/sys/netpfil/pf References: <201411191331.sAJDV9bH092190@svn.freebsd.org> <86tx1nvcy4.fsf@nine.des.no> <86ppcbvb04.fsf@nine.des.no> <86ioi3y0gb.fsf@nine.des.no> Date: Tue, 25 Nov 2014 15:14:56 +0100 In-Reply-To: ("Ermal =?utf-8?Q?Lu=C3=A7i=22's?= message of "Tue, 25 Nov 2014 14:33:30 +0100") Message-ID: <861torxt7j.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 14:15:07 -0000 Ermal Lu=C3=A7i writes: > Also this only affects the traffic sourced by the host itself and not > forwarded traffic and I think this patch will provide a regression for > the issues that the committed patch does. How? The code as it stands (after your commit) is incorrect and will trigger an assertion in vtnet(4). You could argue that it is less incorrect than the original, but the cure is worse than the disease. My patch fixes the panic as well as two preexisting bugs (not taking the IP checksum into account in the IPv4 path, and ignoring hardware offloading). See https://bugs.freebsd.org/192013#c10 for an explanation of what it does and why. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no