On Tue, 6 Dec 2011, Sarah Sharp wrote: > If we can use the SCSI lock to safely set the resetting flag, and stop > uas_queuecommand_lck from submitting new commands until the bus reset > completes, then I think I can see where you're going with the abort > synchronization. > > As you said, we want to abort any commands in flight, which means > stopping uas_do_work() from resubmitting partially queued URBs, and > stopping the status URB completion from submitting more USB 2.0 URBs in > uas_stat_cmplt. Those would be RCU readers, looking at a flag in > uas_cmd_info, possibly a new "aborted" flag in the state variable. > > The RCU writers would be uas_eh_abort_handler and > uas_pre_reset. I know that you said the pre-reset function should just > call the abort handler and let it take care of the synchronization. > However, the abort handler needs the scsi_cmnd pointer, and right now > there's no list of outstanding commands. The UAS driver was really a > fire-and-forget driver until I added the URB anchors. So to be able to > call the abort handler, we'd need a list of outstanding commands, but > walking that list would race with the status completion function > that would take the finished commands off the list, and then we open a > whole new can of worms. Here's one way to do it. Have two new flags: one for reset-in-progress and one for abort-in-progress. If the reset-in-progress flag is set, then uas_do_work and uas_stat_cmplt would know not to submit any URBs at all. If that flag isn't set but the other one is, they would know to check whether the particular command they are working on at the moment is being aborted. Then all you need is some way to tell when all the outstanding commands have completed. For example, an atomic counter of outstanding commands. When the counter goes to 0, if the reset-in-progress flag is set then you signal the pre-reset thread that it may proceed (use a struct completion or something like that). > I'd have to think about this further to see if there's an easier way of > keeping track of commands. I'm not even sure if there's enough room in > uas_cmd_info for a new list_head. Don't sweat the size too much. If you have to, you can make the scratchpad area variable in size. 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
