On Wed, Aug 20, 2014 at 03:18:47PM -0400, Alan Stern wrote:
> On Wed, 20 Aug 2014, Felipe Balbi wrote:
>
> > > > > --- a/drivers/usb/gadget/composite.c
> > > > > +++ b/drivers/usb/gadget/composite.c
> > > > > @@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct usb_composite_dev *cdev)
> > > > > }
> > > > > if (cdev->req) {
> > > > > kfree(cdev->req->buf);
> > > > > + usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
> > > >
> > > > it's best to dequeue the request before freeing its buffer.
> > >
> > > In fact, it's best to wait for the request's completion routine to be
> > > called before freeing the buffer. The hardware can access the buffer's
> > > memory at any time before the completion routine runs.
> >
> > dequeue should cause the transfer to be cancelled and given back.
> > There's a slight possible race window because we release the controller
> > lock in order to call gadget driver's ->complete().
> >
The dp has already been pulled down and the flush pending FIFO buffer
has finished, so the controller should not try to access memory buffer
after that.
> > Other than that, it should be fine. No ?
>
> Dequeue causes the transfer to be cancelled and given back, yes. But
> usb_ep_dequeue() is allowed to return before those things happen.
>
If usb_ep_dequeue is returned before doing any flush and cancel
transfer, it means there is no request on the queue, we don't need
to cancel any requests.
Felipe's suggestion is safe way, we can have a patch for it.
> It depends on the implementation; in general the only way to know that
> the hardware has finished aborting or completing the request is to wait
> until the completion routine is called.
>
> Alan Stern
>
--
Best Regards,
Peter Chen
--
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
