From owner-freebsd-net@FreeBSD.ORG Sat Oct 6 06:59:47 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A62F106566C; Sat, 6 Oct 2012 06:59:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id A616E8FC08; Sat, 6 Oct 2012 06:59:46 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q966xiOc056076; Sat, 6 Oct 2012 10:59:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q966xiJd056075; Sat, 6 Oct 2012 10:59:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 6 Oct 2012 10:59:44 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20121006065944.GW34622@glebius.int.ru> References: <20121005114716.GP34622@FreeBSD.org> <20121005131228.GQ34622@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 06:59:47 -0000 On Fri, Oct 05, 2012 at 05:05:16PM +0200, Ermal Lu?i wrote: E> > E> speaking of pf(4) side of things please do not loose the VIMAGE calls! E> > E> > Yeah, can you explain please why do we need them here? The pfil hooks E> > are always run already in some defined VNET context, don't they? E> E> from my testing at the time these were needed otherwise you will get issues. E> I do not remember the details but i put those there because were required. E> There is no overhead as well from leaving those there. Well, Bjoern and Marko are silent. Let's look ourselves. The most generic case is Ethernet interfaces, and yes, ether_input_internal() sets VNET context. Then packet is demuxed to IP level, ip_input() calls pfil(9) hooks and that all is in defined context. If you remember some issues w/o CURVNET in pf_check_*(), then probably you were using some kind of interface (may be some tunneling) that didn't set VNET context. In this case this is bug in the code of this interface, and not in pf. I will remove CURVNET_SET/RESTORE in a separate commit, not related to byte ordering. -- Totus tuus, Glebius.