From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 05:40:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 673C716A4CE; Sat, 17 Jul 2004 05:40:16 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6H5eFSc088129; Sat, 17 Jul 2004 01:40:15 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6H5eFop088128; Sat, 17 Jul 2004 01:40:15 -0400 (EDT) (envelope-from green) Date: Sat, 17 Jul 2004 01:40:14 -0400 From: Brian Fundakowski Feldman To: "M. Warner Losh" Message-ID: <20040717054014.GP1626@green.homeunix.org> References: <20040715180854.GZ1626@green.homeunix.org> <20040716.232844.15672191.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040716.232844.15672191.imp@bsdimp.com> User-Agent: Mutt/1.5.6i 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:40:16 -0000 On Fri, Jul 16, 2004 at 11:28:44PM -0600, M. Warner Losh wrote: > 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. Do you want to see the driver? This is a simple problem. The removal from the interrupt handler list in pccbb is not even remotely safe with regard to SMP _or_to_interrupts_. I am literally receiving crashes with the function 0xdeadc0de() being called from the interrupts. Do you not believe me? It's extremely easy to test. I just play something on the sound card while I kldunload, or eject, my cardbus wireless card. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\