From owner-cvs-all@FreeBSD.ORG Thu May 1 07:37:25 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BD7C37B404 for ; Thu, 1 May 2003 07:37:25 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF7F43FAF for ; Thu, 1 May 2003 07:37:23 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6422 invoked from network); 1 May 2003 14:37:25 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 1 May 2003 14:37:25 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h41EbKOv025615; Thu, 1 May 2003 10:37:20 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1417270000.1051735953@aslan.btc.adaptec.com> Date: Thu, 01 May 2003 10:37:25 -0400 (EDT) From: John Baldwin To: "Justin T. Gibbs" cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: "M. Warner Losh" cc: Andrew Gallatin Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:37:25 -0000 On 30-Apr-2003 Justin T. Gibbs wrote: >> First off, it's a gross API violation. ithread's are supposed to be >> transparent (except that you can use locks in your interrupt handlers). >> Secondly, you still have the same race as if you just removed the gone >> condition. We don't hold the ithread lock while executing handlers, >> so there is nothing preventing the handler from being executed on another >> CPU concurrently with your detach function. In fact, it could easily >> be blocked on the FXP lock. You do your magic pointer foo, then unlock >> the fxp. The unlock releases the interrupt handler on another CPU >> which happily executes _after_ the completion of bus_teardown_intr() >> which has all sorts of bad failure modes, like panicing when it tries >> to FXP_UNLOCK at the end because back on the first CPU you've done a >> mtx_destroy(). > > I could have sworn I talked to you about this a *long* time ago and > requested that bus_teardown_intr() blocked until you were guaranteed > to be out of the interrupt handler. The aic7xxx and aic79xx drivers > depend on this behavior: Yes, bus_teardown_intr() does block and people were complaining that it does. The only problem that needs to be worked around (which you probably already do) is to make sure that if the handler is currently blocked on the lock when you do the teardown, it will not hose anything (like turn interrupts back on) when it executes. For fxp(4), Warner used a 'gone' flag to make it so that fxp_intr() returned immediately in that case. > This means that all detaches must occur from a context that can > sleep, but that shouldn't be too hard to make happen. People can't hold the driver lock across bus_teardown_intr() with this model, which does require a possibly smarter interrupt routine or maybe a better detach that only disables interrupts then does a teardown, then finishes shutting down the rest of the hardware along with an interrupt handler that doesn't re-enable interrupts in the shutdown case. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/