From owner-svn-src-all@FreeBSD.ORG Tue Feb 12 08:40:30 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B6C4F2E4; Tue, 12 Feb 2013 08:40:30 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id 83753D81; Tue, 12 Feb 2013 08:40:28 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 203094090; Tue, 12 Feb 2013 09:40:21 +0100 From: Hans Petter Selasky To: Adrian Chadd Subject: Re: svn commit: r246614 - head/sys/dev/usb/wlan Date: Tue, 12 Feb 2013 09:41:33 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302101036.r1AAaHs1022034@svn.freebsd.org> <201302120843.32349.hselasky@c2i.net> In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 08:40:30 -0000 On Tuesday 12 February 2013 09:08:44 Adrian Chadd wrote: > Well, how are you preventing the detach from running _during_ an ioctl()? > > Have you eliminated the race, or just narrowed it? > Hi, This is not handled, like you suggest. I'm not sure what the best approach is, but probably we need to destroy the cdev calling the ioctl synchronously first. Do you agree that we need a 3-step proces? 1) Stop everything 2) Drain the stopping 3) Free The problem is atomicity and LOR. Some functions which free resources might have to wait for refcounts to go away, which means blocking operation. I can stop multiple USB transfers atomically, but can I also stop the network stack atomically? Else I need to have those checks around ieee80211_input() and I see btw, that we have to drop the WLAN USB locks to call that function, so it gets a bit more complicated. I.E. we need to stop and drain USB transfers first. There are many USB WLAN drivers, but only one WLAN API. Should these checks be factored out of USB WLAN and into the WLAN API itself? --HPS