From owner-svn-src-head@FreeBSD.ORG Sat May 23 12:00:55 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F73106567C; Sat, 23 May 2009 12:00:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47B048FC0A; Sat, 23 May 2009 12:00:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-107-117-19.carlnfd1.nsw.optusnet.com.au (c122-107-117-19.carlnfd1.nsw.optusnet.com.au [122.107.117.19]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4NC0qL1001147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 22:00:53 +1000 Date: Sat, 23 May 2009 22:00:52 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20090523213159.Y848@delplex.bde.org> References: <200905222303.n4MN3Gsl021718@svn.freebsd.org> <20090522231117.F72053@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, "Bjoern A. Zeeb" , src-committers@FreeBSD.org Subject: Re: svn commit: r192612 - head/sys/netinet X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 23 May 2009 12:00:57 -0000 On Sat, 23 May 2009, Robert Watson wrote: > On Fri, 22 May 2009, Bjoern A. Zeeb wrote: > >> On Fri, 22 May 2009, Bjoern A. Zeeb wrote: >>> ... >>> Log: >>> If including vnet.h one has to include opt_route.h as well. This is >>> because struct vnet_net holds the rt_tables[][] for MRT and array size >>> is compile time dependent. If you had ROUTETABLES set to >1 after >>> r192011 V_loif was pointing into nonsense leading to strange results >>> or even panics for some people. >>> >>> Reviewed by: mz >> >> Thanks to everyone who helped to debug this! > > This sounds like the sort of bug that will recur easily in the future, as the > double array based on configurable dimensions is not a very robust structure > in C. Is there something we can do to make this more robust? For example, > add assertions around consumers that appropriate includes are present in > those consumers? I tried to think of a way to do this automatically for all options headers, but couldn't do it. `#if[n]def' will just always do something. The option testing could have to be written as something like `#if opt(...)', but that is far from automatic and almost as error-prone. For a single option that spams a header like this one, it is probably easy to check it using ifdefs. must not define RT_MAXFIBS unless opt_mroute.h has been included. AT least this option header would have to always #define something to identify itself for this check to be possible. The include should not be in to inhibit growth of this bug and corresponding pollution. IIRC, bz removed it from there as a start to fixing this. still imncludes which includes an enormous amount of pollution. > Also, given that it's a compile-time option, rt_tables > should probably be indirected to so that there isn't an issue with modules > compiled with different kernel options? Especially network device > drivers/modules that may need to use vnet and be distributed as binary ko's? They aren't modules if they are affected by kernel options :-). Aren't there problems with this, else it would have been done. Bruce