From owner-freebsd-net@FreeBSD.ORG Mon Oct 22 10:08:45 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 865C7872; Mon, 22 Oct 2012 10:08:45 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 085C58FC1D; Mon, 22 Oct 2012 10:08:44 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Mon, 22 Oct 2012 12:08:42 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:08:42 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:08:41 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Mon, 22 Oct 2012 12:08:37 +0200 User-Agent: KMail/1.9.10 References: <201210212322.48791.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210221208.37592.zec@fer.hr> X-OriginalArrivalTime: 22 Oct 2012 10:08:41.0884 (UTC) FILETIME=[3694FDC0:01CDB03D] 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: Mon, 22 Oct 2012 10:08:45 -0000 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