(tagging subject more ostensibly as RFC) On Tue, 28 Nov 2017 16:18:36 +0000, Vincent Pelletier <plr.vinc...@gmail.com> 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. 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). Regards, -- Vincent Pelletier -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
