> On Mon, 9 Feb 2004, Stephen Hemminger wrote:
>
>> The following patch fixes the race where a URB is dequeued but it on
>> the complete list. It moves up uhci->list_lock so it overlaps the
>> remove_list lock.
>>
>> This is the important one, the other 9 are just minor improvements
>> that reduce code or memory.
>
> Never mind what I said earlier. I think I figured out what's really
> happening.
>
> A while back I wrote that an URB can't both be unlinked and complete
> normally. Well, that's _supposed_ to be true -- but it isn't quite.
> This is actually something I've wanted to fix for a long time.
>
> The urbp structure includes an unnecessary status member, which does
> little more than duplicate the information in urb->status. This is a
> case where duplication is definitely bad, because the USB core uses
> urb->status to determine whether or not the URB has completed or been
> unlinked, but the UHCI driver was storing the completion code in
> urbp->status instead.
>
> As a result, you can get this sequence of events if the timing is right:
>
> URB completes. Driver stores result in urbp->status; see
> uhci_transfer_result(). Urbp goes on the complete_list.
>
> URB is unlinked. The core sees urb->status == -EINPROGRESS
> still, so it goes ahead and calls uhci_urb_dequeue(). This
> puts urbp on the remove_list.
>
> And there you are. That must have been what happened to you.
>
> The patch below should fix this problem. It gets rid of urbp->status.
> It also takes care of a number of small things that have been bugging
> me for ages:
>
> Close a small loophole by allowing an URB to be unlinked even
> before the uhci_urb_enqueue() procedure has started.
>
> Remove some fossil code from back when interrupt URBs were
> automagically resubmitted.
>
> Giveback unlinked URBs in the order they were unlinked.
>
> Don't set urb->status for dequeued URBs; the core has already
> set it for us.
>
> Rename uhci_remove_pending_qhs to uhci_remove_pending_urbps.
> (That has _really_ gnawed at me!)
>
> Try out this patch, which applies to a virgin driver (without your 10
> patches) and see if it doesn't cure the addressing violation you were
> getting.
Okay, I will try your patch.
I believe, but can't prove the race occurs when:
CPU 0 CPU 1
------------------------------------------------------------------------------
Uhci_irq Uhci_dequeue
delete urb from uhci->urb_list
put on complete_list
delete urb
put it on remove list
Then same urb get's processed twice, once on the complete
list and once on the remove list.
An alternative solution would be to grab complete_list_lock
in uhci_dequeue.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
