On Thu, 30 Nov 2017, Vincent Pelletier wrote: > (tagging subject more ostensibly as RFC) > > On Tue, 28 Nov 2017 16:18:36 +0000, Vincent Pelletier > <plr.vincent@xxxxxxxxx> wrote: > > - This change should have no effect on existing cancel/complete race > > condition, which I expect is already handled in AIO. If not, then it's > > yet another ffs_aio_cancel bug, and this commit will get larger... > > I think I no understand this part: it does not belong to AIO, but to > gadget, namely usb_ep_dequeue vs. dwc3_gadget_giveback. > There actually is a commentin f_fs.c about this: > > usb_ep_dequeue API should guarantee no race condition with > req->complete callback. This is a little misleading. The req->complete callback will be called whether the request is dequeued or not. The real race is between usb_ep_dequeue and completion of the transfer. If usb_ep_dequeue is called before the transfer completes then the dequeue call will succeed, req->status will contain an error value, and the host probably will see some sort of error. If usb_ep_dequeue is called after the transfer completes then the dequeue call will get an error, req->status will be 0 (unless something else went wrong), and the host will see a normal transfer. > So I think there is nothing more to do on this point. > > > - Should anything be done with the return value of usb_ep_dequeue in > > ffs_aio_cancel_worker ? Failures to cancel because transfer is already > > completed or not known should be harmless, but could there be more > > serious issues lurking ? > > From a quick read of a few UDCs, it seems the only error code (EINVAL) > typically means there is nothing to cancel, so it would be fine to > ignore it. > But I would still prefer some advice here (...in addition to the > larger questions from my original mail). The only real reason for usb_ep_dequeue to return an error would be if it was asked to dequeue a request that wasn't currently active. Either the request was never submitted or else it has already completed. Either way, there is probably not much you can do about it. Alan Stern -- 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
