MFC VIMAGE fixes to 11-stable

[Marko Zec]

On Thu, 20 Apr 2017 15:13:42 +0200
Kristof Provost <kristof at sigsegv.be> wrote:

> On 20 Apr 2017, at 12:42, Marko Zec wrote:
> > The real culprit lies somewhere in PF code which operates on a wrong
> > vnet.  Without a backtrace it's difficult to guess, but a quick read
> > reveals that
> >
> > pfi_initialize()
> >
> > is called from the default vnet context, and subsequently registers
> > interface eventhandlers so that all interface attach, change and 
> > detach
> > events will be always executed in the default vnet, regardless of
> > the real vnet where the interfaces bound to the events actually
> > reside. In
> > other words,
> >
> > pfi_attach_group_event()
> > pfi_change_group_event()
> > pfi_detach_group_event()
> >
> > will operate fine only in the default vnet, but will wreak havoc
> > otherwise.  Hence, those handlers should be fixed first.
> >  
> I don’t think that’s right.
> 
> The event handler doesn’t carry vnet information.  It’s just called 
> in whatever vnet is active when it’s invoked.
> There's no CURVNET_SET() in the EVENTHANDLER_INVOKE() macro.
> 
> That means that we end up in pf_attach_group_event() with CURVNET set
> to the relevant vnet, not to the default vnet.

Right.  But pfi_attach_group_event() and the other handlers cited above
_do_ in fact invoke CURVNET_SET(vnet0) on entry, overriding the proper
vnet choice from the caller.

Therefore the proper fix should be as simple as removing CURVNET_SET() /
CURVNET_RESTORE() macro pairs from the cited handlers.

Marko


> 
> There are certainly still issues with pf and vnets, but I don't think 
> this is
> one.
> 
> Regards,
> Kristof