From owner-freebsd-net@FreeBSD.ORG Sun Oct 21 23:03:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 676F884D; Sun, 21 Oct 2012 23:03:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA838FC0C; Sun, 21 Oct 2012 23:03:19 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1605201pbb.13 for ; Sun, 21 Oct 2012 16:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MgcSrK6YkEFyCt6yEqt9hLK1mIzs6+21zehB/85verY=; b=D7gefFSv83/pcKrTLg2sMOhsp46v9QIIU2NVVkF2Mv7TByZp+TAT6D/6kkrYuTjNaq 0doRkxgIBXZfin2miuL0oO+AK5YsoMGj8BQaVFYhoiH40p/J0oYh2s7AAF8Mh+CJIi/t LuNlAaUH0tpmbITtsfXDDEzBBl5GUG7iRHfxCrNkVftzYymktpU78YiKt/tkm679oaCr 1eiobWp+Gr8HUPHa0yNlkRshOuzlHJu63zvx0WcvZEOVzxTjxZe586mIxmPdj2H+OgC/ W9mMieFr8YpjjevBt3/LgnE8Y0FDsK63SN3A5AERgSKXDbXKpVzmo6RqiYUd8ab32jeJ Jn0Q== MIME-Version: 1.0 Received: by 10.66.78.199 with SMTP id d7mr21235671pax.77.1350860599701; Sun, 21 Oct 2012 16:03:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 21 Oct 2012 16:03:19 -0700 (PDT) In-Reply-To: <201210212322.48791.zec@fer.hr> References: <201210212136.12788.zec@fer.hr> <201210212322.48791.zec@fer.hr> Date: Sun, 21 Oct 2012 16:03:19 -0700 X-Google-Sender-Auth: 8G4_jzbZ1V8ahBqzP7sb3BbEy54 Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 23:03:20 -0000 On 21 October 2012 14:22, Marko Zec 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