On Fri, Dec 09, 2011 at 10:17:02AM +0100, Sebastian Andrzej Siewior wrote: > * 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. Yes, I've actually run into an issue with the RCU bits and the workqueue, which made me finally decide to rip out the thing. The workqueue is global, which means my assumptions about using the devinfo-specific resetting flag to stop the workqueue don't hold true. If there are two devices, and one of them is resetting, the other UAS driver instance will happily continue to submit things to the workqueue because its resetting flag is cleared. Sarah Sharp -- 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
