* Sarah Sharp | 2011-12-02 11:55:44 [-0800]: >If the original submission (or allocation) of the URBs for a SCSI >command fails, the UAS driver sticks the command structure in a >workqueue and schedules uas_do_work() to run. That function removes the >entire queue before walking across it and attempting to resubmit. > >Unfortunately, if the second submission fails, we will leak memory >(because an allocated URB was not submitted) and possibly leave the SCSI >command partially enqueued on some of the stream rings. Fix this by >checking whether the second submission failed and re-queueing the >command to the UAS workqueue and scheduling it. Yes, I like it. However I think you shouldn't requeue the command for ever. If something went wrong for the first time why should it change in future? -ENOMEM is something that may change in the future. If the evil gadget responded with IU_ID_READ_READY instead of IU_ID_WRITE_READY it makes no sense to retry :) The scsi layer will take the command back at some point but until then you keep the system busy. Sebastian -- 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
