PERFORCE change 167260 for review
Marko Zec
zec at freebsd.org
Wed Aug 12 22:35:13 UTC 2009
On Wednesday 12 August 2009 23:58:46 Julian Elischer wrote:
> Marko Zec wrote:
...
> > @@ -710,22 +715,36 @@
> > .pr_input = div_input,
> > .pr_ctlinput = div_ctlinput,
> > .pr_ctloutput = ip_ctloutput,
> > - .pr_init = NULL,
> > + .pr_init = div_init,
> > .pr_usrreqs = &div_usrreqs
>
> If you are going to make pr_init() called for every vnet then
> pr_destroy should be as well. But in fact that is not really safe.
> (either of them)
>
> The trouble is that we can not guarantee that other protocols can
> handle being called multiple times in their init and destroy methods.
> Especially 3rd party protocols.
>
> We need to ensure only protocols that have been converted to run
> with multiple vnets are ever called with multiple vnets.
>
> for this reason the only safe way to do this is via the VNET_SYSINIT
> and VNET_SYSUNINIT calls.
That would mean you would have to convert most if not all of the existing
things that hang off of protosw-s in netinet, netinet6 etc. to use
VNET_SYSINT / VNET_SYSUNIT instead of protosw->pr_init(). So the short
answer is no.
I cannot recall that we ever discussed or planned to be able to mix
virtualized with non-virtualized protocols in the same kernel. That would be
a horrible mess, and I cannot even imagine having say a multi-instance INET
with a single-instance INET6 kernel, shared among all the vnets. To start
with, how would you decide that you're not allowed to process an IPv6 packet
received on the wire in a non-default vnet in such an environment? Do we
have the infrastructure in place necessary for preventing doing say a
ifconfig lo0 ::1 in a non-default vnet in such an hypotetical setup? The
answer is no.
VNET_SYSINIT is nice, but proper special-casing changes required to support
single-instance protocols to work only with vnet0 and not with the other
protocols are simply not there, and I hope will never be, because I fear they
would be highly intrusive, difficult to verify and maintain, and probably
also have an impact on performance.
A proper solution for the issue you are raising could be something that would
prevent modules assuming our stack is compiled as single-instance to be
kldloaded if the kernel was actually built with multi-instance stack support.
I think Robert (cc-ed) had some ideas on how to accomplish this by having
such modules depend on a magic global variable (say __no_vnet_support) to be
available.
All the current "base" protocols are already using pr_init() in multi-instance
mode in options VIMAGE case. So I see no reason for ip_divert not being
allowed to leverage on the same mechanism.
Re. pr_destroy(), you're right, patch already submitted to p4...
Marko
More information about the p4-projects
mailing list