From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 05:29:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77DAC16A4CE; Sat, 17 Jul 2004 05:29:32 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F84543D39; Sat, 17 Jul 2004 05:29:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6H5SbHh003733; Fri, 16 Jul 2004 23:28:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 16 Jul 2004 23:28:44 -0600 (MDT) Message-Id: <20040716.232844.15672191.imp@bsdimp.com> To: green@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040715180854.GZ1626@green.homeunix.org> References: <20040715180854.GZ1626@green.homeunix.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: pccbb crashes when detaching (unsafe interrupt handler) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2004 05:29:32 -0000 In message: <20040715180854.GZ1626@green.homeunix.org> Brian Fundakowski Feldman writes: : Devices that attach to a pccbb end up getting screwed if they share : interrupt handlers with anything else and one comes in at such time : that the interrupt handler has been deallocated but not torn down. How do they get screwed by this case? I considered these cases. What scenario, exactly, does this cause problems for. : There is no interrupt protection for the pccbb interrupt handler, There doesn't need to be one because we preclude calling it when things are in a bad state. Is there some case that we've not taken care of? : and the cleanest method I can think of is add a "don't run" count to : the real ithread interrupt handler (parent); however, this is a fair : bit of infrastructure if it's not something very useful, and in SMP, : concurrent accesses of the local interrupt handler list in pccbb do : need to be protected, not just preventing interrupt handlers. I don't think this sort of insfrastructure is useful. I don't understand when the case you are trying to protect against can happen, so I'm having trouble seeing why the code is necessary. : This is what I have so far, but I'm not happy with it because it : seems like it would be so much nicer to increment a count on the : ithread's intrhand and drain any current interrupt out of the : ithread, but possibly making each interrupt a lot more expensive. Like I said in another note, I don't like this because I don't want to take out a lock on every interrupt to guard against such a rare case as you've discovered (I'm assuming it is rare becuase I've never seen it in 5 years of maintaining the code). ... : if (sc->flags & CBB_CARD_OK) { ... What I want to know is why the above check doesn't guard against this problem. If the card is detached because you ejected it, the isr already guards against calling the hanlders for this card. Warner