My original description of the race was: > there's ALWAYS a race on SMPs between completion handler > finishing with that URB, and other driver code reusing it.
In more detail, HCD code on some CPU will set the "flag" value, probably a short while before it calls the completion handler. Starting at that instant, device driver code running any other CPU could test it, and conclude (falsely) that the urb is reusable. But that flag will be set before the completion function is invoked, and certainly before it's finished. Ergo, race on SMP. URBs can only be reused after the completion handler finishes. In the skeleton driver, that wouldn't break much, except it'd cause a false diagnostic -- but drivers derived from it would normally do real work in those handlers. ----- Original Message ----- From: "Oliver Neukum" <[EMAIL PROTECTED]> To: "David Brownell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, January 14, 2002 1:11 AM Subject: Re: [linux-usb-devel] Re: two bugs in usb-skeleton > > An ISR would be part of the HCD ... so my earlier comments > > apply. That can't work. And the work doesn't actually need > > to be done in_irq(), fwiw. > > > > > Thus, doing it with a flag (and both the urb->dev and the > > > urb->status methods are effectively flags) is difficult > > > > "not possible" ... as with the "urb->users" flag you sketch. > > The race begins when such a flag's value changes (in the > > hcd parts of usbcore) and ends when the completion routine > > finishes its work on the URB. > > But the decrementing of the counter would be the last thing > the isr does. I am probably dense here. Could you explain > the race in greater detail ? > > Regards > Oliver _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
