RFC: Enabling VIMAGE in GENERIC

[Alexander V. Chernikov]

On 19.11.2014 07:28, Craig Rodrigues wrote:
> On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein <alfred at freebsd.org>
> wrote:
>
>> On 11/17/14, 3:02 AM, Warner Losh wrote:
>>
>>> On Nov 17, 2014, at 12:46 AM, Craig Rodrigues <rodrigc at 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-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>