VIMAGE crashes on 9.x with hotplug net80211 devices

Marko Zec zec at fer.hr
Mon Oct 22 10:08:45 UTC 2012


On Monday 22 October 2012 01:03:19 Adrian Chadd wrote:
...
> > Obviously, handling device attach events is an exception from this
> > rule, and up to this date this was never properly addressed...
>
> *laugh*.
>
> The problem now is figuring out how to do it without modifying all the
> drivers.
>
> The attach is easy - I can likely set it up during the device_attach()
> pass. I can do that, but it's enforcing "networking-ness" with the
> device attach, which will be called for networking and non-networking
> devices alike.
>
> However detach isn't easy - because I'm required to call
> CURVNET_SET(ifp->if_vnet) and CURVNET_RESTORE() around if_free(), and
> if_free() is called in the device specific detach() routine, I can't
> easily set the current VNET context from outside the driver.
>
> I _guess_ I could device_attach() to use CURVNET_SET(vnet0) but
> device_detach() can't do the same - it doesn't "know" about the
> networking-ness of the device.
>
> I'm open to other suggestions.

The only option I can think of now is to update all of the hotunpluggable 
device_detach() handlers to do CURVNET_SET(ifp->if_vnet) before calling 
further down into the networking stack, because as you already observed, 
whatever triggers a device_detach() handler is not aware of the nature of 
the driver.

> (how the hell does this work for devices attached at probe time? What
> vnet context do they have, and why doesn't the kernel panic there?)

Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 
between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP).

Similarly, curvnet is set to vnet0 during kldload events.

Marko


More information about the freebsd-hackers mailing list