Date: Sat, 23 May 2009 22:00:52 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Robert Watson <rwatson@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, src-committers@FreeBSD.org Subject: Re: svn commit: r192612 - head/sys/netinet Message-ID: <20090523213159.Y848@delplex.bde.org> In-Reply-To: <alpine.BSF.2.00.0905230909170.75344@fledge.watson.org> References: <200905222303.n4MN3Gsl021718@svn.freebsd.org> <20090522231117.F72053@maildrop.int.zabbadoz.net> <alpine.BSF.2.00.0905230909170.75344@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <net/route.h> 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 <net/route.h> to inhibit growth of this bug and corresponding pollution. IIRC, bz removed it from there as a start to fixing this. <net/vnet.h> still imncludes <net/if_var.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090523213159.Y848>