Hi,
> The function musb_urb_enqueue contains the following code:
>
> if (hep->hcpriv) {
> /* some concurrent activity submitted another urb to
> hep...
> * odd, rare, error prone, but legal.
> */
> kfree(qh);
> ret = 0;
This condition wouldn't occur as hep->hcpriv is being set (=qh) at
musb_schedule(). At this point hep->hcpriv is suppose to be NULL otherwise
we would not even have come so far. See the initial code snippet of this function,
-------------------------------------------------
spin_lock_irqsave(&musb->lock, flags);
ret = usb_hcd_link_urb_to_ep(hcd, urb);
qh = ret ? NULL : hep->hcpriv;
if (qh)
urb->hcpriv = qh;
spin_unlock_irqrestore(&musb->lock, flags);
if (qh || ret)
return ret;
-------------------------------------------------
Regards,
Ajay
> } else
> ret = musb_schedule(musb, qh,
> epd->bEndpointAddress &
> USB_ENDPOINT_DIR_MASK);
>
> if (ret == 0) {
> urb->hcpriv = qh;
> /* FIXME set urb->start_frame for iso/intr, it's tested in
> * musb_start_urb(), but otherwise only konicawc cares ...
> */
> }
>
> Since the then branch of the first if sets ret to 0, the then branch of
> the second branch will be executed, possibly leading to a use of qh after
> it has been freed. Could it be that the second if is suppoed to beunder
> the else of the first one?
>
> julia
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
