VIMAGE crashes on 9.x with hotplug net80211 devices

[Marko Zec]

On Sunday 21 October 2012 21:50:21 Adrian Chadd wrote:
> On 21 October 2012 12:36, Marko Zec <zec at fer.hr> wrote:
> > The right approach would be to do a single CURVNET_SET(vnet0) /
> > CURVNET_RESTORE() somewhere near the root of the call graph being
> > triggered by the hotplug attach event.  Not having any hotpluggable
> > hardware at hand I cannot be more specific where that place could be...
>
> Right; would that be at the net80211 side, or something higher up (eg
> at device_attach, which gets called from the cardbus/pci bridge
> enumeration code.)

As high as it gets - if you get lucky, as a side effect you might even fix 
similar issues with USB hotplugging.

> > But most certainly doing CURVNET_SET(vnet0) on detach events would be
> > wrong: since ifnets may be assignet to non-default vnets,
> > CURVNET_SET(ifp->if_vnet) should be more appropriate there.
>
> Thanks for that. I'll look at adding that in my next debug pass.
>
> > Another thing that may help could be turning on options VNET_DEBUG
> > when, as that should reveal excessive (and probably redundant)
> > CURVNET_SET() recursions.
>
> I've spotted a couple, however the crashing here is the important bit.
> :-)
>
> So - why is it that the V_* variables are NULL pointers at this stage?
> I thought the kernel would've been running with a default vnet context
> of vnet0? Why doesn't this impact other network device hotplugging? Or
> does it, and noone noticed?

By design, the kernel is never running "by default" in any of the vnets 
(vnet0 included).  If it were, it would be extremely difficult to spot and 
catch many cases where a subsystem would be (implicitly) working with 
vnet0, while in fact it should be working in a different vnet context.

Obviously, handling device attach events is an exception from this rule, and 
up to this date this was never properly addressed...

Marko