Date: Sun, 21 Oct 2012 16:03:19 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Marko Zec <zec@fer.hr> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Message-ID: <CAJ-VmokH2VqK-5of2%2B79mKbQ9m61tTvdqCCSJkj3EPejmDaH=A@mail.gmail.com> In-Reply-To: <201210212322.48791.zec@fer.hr> References: <CAJ-VmomchJZ7GUKrAjmmyBXDw-6H6O5fAxT_tfAFfhU=HknG1g@mail.gmail.com> <201210212136.12788.zec@fer.hr> <CAJ-Vmom1-zYuArGTG5hkft2aBtFDSfBSn1r90qDpu7nejyXwRw@mail.gmail.com> <201210212322.48791.zec@fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 October 2012 14:22, Marko Zec <zec@fer.hr> wrote: >> 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. Right. There's three problems: * the device attach (ath_attach, calls if_* calls) * the net80211 device attach; * the net80211 vap attach. There's also detaching all of the above too. >> 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. Right. Well, that's why it's panicing then. > 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. (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?) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokH2VqK-5of2%2B79mKbQ9m61tTvdqCCSJkj3EPejmDaH=A>