From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 18:49:52 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 56C3716A521; Sat, 17 Jul 2004 18:49:51 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCD2B43D2D; Sat, 17 Jul 2004 18:49:50 +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 i6HIlu4U001767; Sat, 17 Jul 2004 12:47:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 17 Jul 2004 12:48:03 -0600 (MDT) Message-Id: <20040717.124803.33210527.imp@bsdimp.com> To: green@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20040717182841.GR1626@green.homeunix.org> References: <20040717054014.GP1626@green.homeunix.org> <20040717.121712.83689795.imp@bsdimp.com> <20040717182841.GR1626@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 18:49:52 -0000 In message: <20040717182841.GR1626@green.homeunix.org> Brian Fundakowski Feldman writes: : It's just as unfair for you to use hyperbole and deny it as a problem : or basically call me a liar, but I'm glad at least you're admitting it : is a problem now. You are taking offence where none was intended. I didn't call you a liar, I just said that I've *NEVER* seen the problem in the last 4 years of working with the code. There's a big difference. 4 years of trouble free operation for as much as I use the code is enough to bias the burdon of proof for a race that's been there for those 4 years to the submitter... Races seem obvious in hindsight, but are difficult to find so explaination of them is key in getting the problem understood. : You need to use atomic/SMP-safe synchronizations, : and that does not come at zero cost. There is a race between the driver : checking if the card is still "okay" and running the interrupt handler : that is impossible to solve without at least two atomic operations. : : Zero will not do. Agreed. The eject case is easy to guard against (since pccbb turns off interrupt forwarding immediately when it detects the card is gone and we detach in a separate thread). The unload case is the more difficult to deal with since interrupts may come in during the unload process and you can't guard against them all. You can't turn off the interrupt stream in that case because there may be more than one function on the card. : Be pissed off all you want, Warner. I think this is a counter productive attitude, and an uncalled for cheap shot. Let's stop that part of this conversation and get onto solving the problem at hand. : FreeBSD 5.x is not based on the spl : model anymore, and unless you want to ADD the ability to do something like : that, which is certainly quite feasible (that is, add a "blocking" count : to the interrupt handler, which the ithread has to ack before you can : return with the interrupt "blocked") there will be a specific cost inside : the pccbb driver to do things safely and it will involve some sort of : synchronization. I don't assume that things are spl based, I just had never seen the race that you found. I don't want to use sx locks to solve this because I'd one day like to make the cbb isr a fast interrupt handler so that we can restore fast interrupt handlers to pccard and cardbus modems. sx locks sleep, and can't be used in a fast interrupt handler. Warner