Re: kernel panic when called usb_control_msg()

[Alan Stern]

On Fri, 3 Aug 2012, y b wrote:

> Hi,
> kernel panic when called usb_control_msg(), like this:
>    usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
> XR_SET_REG, USB_DIR_OUT | USB_TYPE_VENDOR, value, regnum | (block <<
> 8), NULL, 0, 5000)
> The kernel's version is 2.6.33_rc4, but I think it will happen in
> lastest statable version too.

> I fixed it like this:
> 
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index 4bb717d..b043f27 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -2056,9 +2056,15 @@ static int musb_urb_enqueue(
>         kfree(qh);
>         qh = NULL;
>         ret = 0;
> -   } else
> -       ret = musb_schedule(musb, qh,
> -               epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK);
> +   } else {
> +       if (!next_urb(qh)) {
> +           kfree(qh);
> +           qh = NULL;
> +           ret = 0;
> +       } else
> +           ret = musb_schedule(musb, qh,
> +                   epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK);
> +   }
> 

You could shrink this patch a lot:

	 * we only have work to do in the former case.
	 */
	spin_lock_irqsave(&musb->lock, flags);
-	if (hep->hcpriv) {
+	if (hep->hcpriv || !next_urb(qh)) {
		/* some concurrent activity submitted another urb to hep...
		 * odd, rare, error prone, but legal.
		 */

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/