On Wed, Oct 23, 2002 at 05:34:53PM +0200, Oliver Neukum wrote: > > > I'm going to guess that you will object to the race condition that exists > > between the time the flag is tested and the URB is submitted. Yes, > > there's a race. But it is unavoidable, unless you want to surround every > > call to the usb core with a spinlock_irq or the equivalent. And in any > > That's exactly what's needed. But why irq? Disconnect() runs from task > context.
Ah, but re-submission of an interrupt URB from within the completion
handler will run in interrupt context.
This could also be entirely solved by making the requirements that:
(1) The core or HCD will unlink all URBs for a removed device when
it's removed
(2) The mid- and high-level drivers will not submit any more URBs
to the removed device once the disconnect() routine has ended.
If you think about it, some of this is needed anyway. After all, there
will always be the fundamental race of the cable being pulled, and URB
being submitted, and then the disconnect function getting called. We could
require the disconnect to unlink the URBs, but since the core/HCDs have to
be able to accept (at least for a small window) URBs for a removed device,
why not put the logic all in one place?
After all, it used to work this way....
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
What, are you one of those Microsoft-bashing Linux freaks?
-- Customer to Greg
User Friendly, 2/10/1999
msg08673/pgp00000.pgp
Description: PGP signature
