>
> I'm currently checking chipidea udc on our platform and I can see some
> "freeing queued request" message (some bad behaviour from android adb
> gadget driver).
>
> After this message we exit without freeing anything :
>
> static void ep_free_request(struct usb_ep *ep, struct usb_request *req) {
> (...)
> if (ep == NULL || req == NULL) {
> return;
> } else if (!list_empty(&hwreq->queue)) {
> dev_err(hwep->ci->dev, "freeing queued request\n");
> return;
> }
> (...)
> kfree(hwreq);
>
> I checked on other gadget drivers:
> - amd5536udc, at91_udc, lpc32xx_udc will BUG_ON(!list_empty(&req->queue));
> - pch_udc.c will dev_err but not return
> - a lot will WARN_ON (!list_empty (&req->queue));
> - and some will not check it
>
> As far as the gadget.h says, the caller of usb_ep_free_request guarantees
> the request is not queued, and that it will no longer be requeued (or
> otherwise used).
>
> But maybe a WARN_ON should be a better strategy ? or am I lacking
> something ?
>
Hi Francois,
A dev_err dump message and return are suitable, if there are still
some requests queued at list, we can't free this request queue, otherwise,
we can't handle the requests which may be finished soon.
Just like the gadget.h says, the caller should guarantee the request is
not queued before calling free_request, if the caller finds the udc layer
does not return correct data, it should call usb_ep_dequeue to cancel
this request.
What do you mean the memleak, the memleak for this request? Like I said
above, the caller may need to call usb_ep_dequeue first.
Peter
> Regards,
>
> François MULLER
> --
> 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
