On 03.07.13, Ming Lei wrote:
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 014dc99..26471cd 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -1648,6 +1635,72 @@ int usb_hcd_unlink_urb (struct urb *urb, int status)
>
> /*-------------------------------------------------------------------------*/
>
> +static void __usb_hcd_giveback_urb(struct urb *urb)
> +{
> + struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus);
> + int status = urb->unlinked;
> + unsigned long flags;
> +
> + urb->hcpriv = NULL;
> + if (unlikely((urb->transfer_flags & URB_SHORT_NOT_OK) &&
> + urb->actual_length < urb->transfer_buffer_length &&
> + !status))
> + status = -EREMOTEIO;
> +
> + unmap_urb_for_dma(hcd, urb);
> + usbmon_urb_complete(&hcd->self, urb, status);
> + usb_unanchor_urb(urb);
> +
> + /* pass ownership to the completion handler */
> + urb->status = status;
> +
> + /*
> + * We disable local IRQs here avoid possible deadlock because
> + * drivers may call spin_lock() to hold lock which might be
> + * acquired in one hard interrupt handler.
> + *
> + * The local_irq_save()/local_irq_restore() around complete()
> + * will be removed if current USB drivers have been cleaned up
> + * and no one may trigger the above deadlock situation when
> + * running complete() in tasklet.
> + */
> + local_irq_save(flags);
> + urb->complete(urb);
> + local_irq_restore(flags);
How can there be a dead lock if you always complete in the same context
(either BH or hardirq) for a given device [0]?
Why do you choose to complete in BH context instead using threaded irqs
and complete in the thread?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
