On 19.11.2014 07:28, Craig Rodrigues wrote:
On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein <alf...@freebsd.org>
wrote:
On 11/17/14, 3:02 AM, Warner Losh wrote:
On Nov 17, 2014, at 12:46 AM, Craig Rodrigues <rodr...@freebsd.org>
wrote:
(3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO
and
https://bugs.freebsd.org/bugzilla/buglist.cgi?
quicksearch=vimage%20or%20vnet
and try to clean things up. Get help from net@ developers to
do
this.
And if these don't get cleaned up?
If they are not cleaned/stable up by 11-RELEASE then we turn it off. That
is simple.
Yes, I agree with Alfred that we can turn VIMAGE back off before
11-RELEASE if things don't get cleaned up.
We have approximately until the end of 2015, so that gives
us time.
(4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from
the ipfilter maintainers for this and some net@ developers.
And if this doesn't happen?
Well we do have 2 other firewalls in the kernel to pick, but we do need
VIMAGE so I will let you draw your own conclusions.
Again, I agree with Alfred on this. Darren Reed originally imported
ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a
while. Cy Schubert has recently expressed interest in ipfilter and has
committed some fixes in the past year, but has not fixed the VIMAGE problems
( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ).
I can take an initial effort at trying to fix VIMAGE + ipfilter.
In the past, I've delved into areas I'm not so familiar with in
order to fix VIMAGE + Bluetooth. If Cy can provide any knowledge or
guidance, that will be great.
A lot of bug fixes have gone into VIMAGE in the past 2 years,
and I have received multiple reports of people using it in production
environments. See the latest post by Peter Ross.
To flush out the last few issues and corner cases, I think we
need to turn VIMAGE on by default and get feedback and help from
the FreeBSD user community and developers to identify and fix the problems.
Can we have some wiki/man/docs on how particular subsystem should
interact with VNET first?
This can probably help to make proper vnet fixes in less number of
attempts :)
For example, even attach/detach is handled differently in different places:
tcp_subr.c:
/* Skip initialization of globals for non-default instances. */
if (!IS_DEFAULT_VNET(curvnet))
return;
in6_rmx.c:
/*
* Initialize our routing tree.
*/
static VNET_DEFINE(int, _in6_rt_was_here);
#define V__in6_rt_was_here VNET(_in6_rt_was_here)
if (V__in6_rtwas_here == 0) {
callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE);
in6_mtutimo(curvnet); /* kick off timeout first time */
V__in6_rt_was_here = 1;
}
return (1);
}
It would be great to get a bit more details on the following (at least
from my point of view):
* what is the proper procedure of handling non-default VNET
attach/detach (locking mostly)
* how can one properly cache needed VNET context (e.g. is it safe just
to save "struct vnet *" pointer) and is this right thing to do at all?
* Is it safe to to CURVNET_SET without holding any VNET locks ?
P.S. I'm not against VIMAGE in any kind, I think we really should move
forward towards making it stable.
However, "just turn it on" concept with a bunch of known (and unresolved
issues) is not the best thing IMO.
We have about 1 year until 11-RELEASE, so I think it is OK to do this.
I would also add two items to my action plan.
(6) Ask clusteradm to run one of the machines they use
for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide
feedback.
(7) Ask for help with testing from companies who have more involvement
with the network stack. Two of the people in the CC: line of this
e-mail work for such places. :)
--
Craig
--
Craig
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
