svn commit: r192612 - head/sys/netinet
Bruce Evans
brde at optusnet.com.au
Sat May 23 12:00:57 UTC 2009
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
More information about the svn-src-all
mailing list