From owner-freebsd-net@FreeBSD.ORG Fri Jan 2 16:41:25 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EF26185 for ; Fri, 2 Jan 2015 16:41:25 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 019901ACE for ; Fri, 2 Jan 2015 16:41:24 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 49A0A7300A; Fri, 2 Jan 2015 17:45:59 +0100 (CET) Date: Fri, 2 Jan 2015 17:45:59 +0100 From: Luigi Rizzo To: "Alexander V. Chernikov" Subject: Re: host pipes and netmap 'emulated mode' Message-ID: <20150102164559.GA68836@onelab2.iet.unipi.it> References: <54A6BAE0.9020404@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A6BAE0.9020404@yandex-team.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Jan 2015 16:41:25 -0000 On Fri, Jan 02, 2015 at 06:36:00PM +0300, Alexander V. Chernikov wrote: > Hello list. > > It looks like it is impossible to use host pipes and emulated netmap > mode in some cases. > > For example, if you're doing something like what traditional router do: > packet processing, with kernel-visible logical interfaces, routing > daemon running there, you can easily get a panic like this: > > #0 0xffffffff8094aa76 at kdb_backtrace+0x66 > #1 0xffffffff809104ee at panic+0x1ce > #2 0xffffffff80cf9660 at trap_fatal+0x290 > #3 0xffffffff80cf99c1 at trap_pfault+0x211 > #4 0xffffffff80cf9f89 at trap+0x329 > #5 0xffffffff80ce30d3 at calltrap+0x8 > #6 0xffffffff809d3b5f at ether_demux+0x6f > #7 0xffffffff809d3f34 at ether_nh_input+0x204 > #8 0xffffffff809dd6d8 at netisr_dispatch_src+0x218 > #9 0xffffffff8061b2b5 at netmap_send_up+0x35 > #10 0xffffffff8061b3d7 at netmap_txsync_to_host+0x97 > #11 0xffffffff8061b400 at netmap_txsync_to_host_compat+0x10 > #12 0xffffffff8061de8c at netmap_poll+0x2fc > #13 0xffffffff807f2313 at devfs_poll_f+0x63 > #14 0xffffffff8095ea3d at sys_poll+0x35d > #15 0xffffffff80cf8e0a at amd64_syscall+0x5ea > #16 0xffffffff80ce33b7 at Xfast_syscall+0xf7 > Uptime: 4m21s > > The problem here is the following: > netmap changes if_input() for the logical network interface and always > assumes that generic_rx_handler() is called with netmap-enabled ifp > (e.g. original inteface). > Unfortunately, there are cases where we have different ifp passed to > if_input handler. This particular case is triggered by > (*ifp->if_input)(ifv->ifv_ifp, m); > line, where "ifp" represents netmap-enabled NIC, and ifv->ifv_ifp > represents vlan subinterface. > > Then, generic_rx_handler() tries to looking NA/GNA structure but fails > since vlan subinterface is not netmap-enabled. > So, it looks like that we need a way to call original if_input() but I > can't imagine (good) one/ Surely we can put a check in generic_rx_handler() to make sure that NA(ifp) is NULL -- this is already a relatively expensive code path so the extra checks won't harm. But I am a bit unclear on how you trigger this error, can you give me more details ? The offending instruction (*ifp->if_input)(ifv->ifv_ifp, m) is in vlan_input(), so it looks like you are setting the parent interface in netmap mode, and (looking at the trace) sending packets to the host port. So i suppose the error path is when netmap_send_up() calls the original input handler, NA(ifp)->if_input [i should rename the field to something else] which is vlan_input(). I think a proper fix is to make vlan_input() netmap aware, and call NA(ifp)->if_input if the interface is in netmap mode. Otherwise, if vlan_input() is the only case where if_input() is called with a different ifp, _and_ the vlan (child) interface has a reference to the parent (ifp->parent, though i don't know where this is), we can tweak generic_rx_handler() so that it calls NA(ifp->parent)->if_input in case NA(ifp) is null. cheers luigi