Date: Sat, 17 Jul 2004 12:48:03 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: green@FreeBSD.ORG Cc: current@FreeBSD.ORG Subject: Re: pccbb crashes when detaching (unsafe interrupt handler) Message-ID: <20040717.124803.33210527.imp@bsdimp.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040717182841.GR1626@green.homeunix.org>
Brian Fundakowski Feldman <green@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040717.124803.33210527.imp>