Date: Sun, 21 Oct 2012 23:22:48 +0200 From: Marko Zec <zec@fer.hr> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Message-ID: <201210212322.48791.zec@fer.hr> In-Reply-To: <CAJ-Vmom1-zYuArGTG5hkft2aBtFDSfBSn1r90qDpu7nejyXwRw@mail.gmail.com> References: <CAJ-VmomchJZ7GUKrAjmmyBXDw-6H6O5fAxT_tfAFfhU=HknG1g@mail.gmail.com> <201210212136.12788.zec@fer.hr> <CAJ-Vmom1-zYuArGTG5hkft2aBtFDSfBSn1r90qDpu7nejyXwRw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 21 October 2012 21:50:21 Adrian Chadd wrote: > On 21 October 2012 12:36, Marko Zec <zec@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210212322.48791.zec>