On Thu, 8 Dec 2011, Sarah Sharp wrote: > > Just wait until the command completes, one way or another, and return > > success. Or maybe return FAST_IO_FAIL, which doesn't appear to be > > documented anywhere but is used in the SCSI error handler. > > That could make things a bit complicated between pre-reset and the abort > handler. Would it be unwise to make the abort handler wait on the reset > flag? The commands will certainly be done by that point. I'm not sure what you mean. The resetting flag may get set before anything is cancelled. The abort handler should not worry about possible resets (apart from not sending an ABORT TASK when a reset is in progress); let the reset handler worry about those interactions. The abort handler should simply wait until the command and the abort have both completed. (You don't want it to return too early because then the SCSI layer might reuse one of the two tags.) > Would waiting > too long in the abort handler cause the error handling for other SCSI > devices to be held up for too long, since there's only one error > handling thread? There's one error-handling thread _per SCSI host_. Plug in a USB flash drive, run "ps -A | grep scsi_eh", and you'll see. > > The only thing to watch out for would be if the completion handler gets > > rid of some data structure while the abort handler is still using it. > > If that's not an issue in uas then there's nothing to worry about. > > I expected that the completion handler would run for a killed URB, and > made sure the handlers would free the URBs and their buffers regardless > of the URB status. The abort task handler only frees URBs that were > never submitted (the ones that were allocated but sitting in the > workqueue). So I think we should be fine. Okay, as long as you don't have any other privately-allocated data associated with each command, you're good. At first I was worried that the completion handler might deallocate the anchor, but looking back I see that you used a fixed array of anchors stored in the devinfo structure. > > I hope things are a little clearer now. > > Yes, much clearer, thank you. I'll have to think about this for a bit > before I come up with a better patchset. Good. 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
