uas: Remove task-management / abort error handling code
There are various bug reports about oopses / hangs with the uas driver, which all point to the abort-command and logical-unit-reset (task-management) error handling paths. Getting these right is very hard, there are quite a few corner cases, and testing is almost impossible since under normal operation these code paths are not used at all. Another problem is that there are also some cases where it simply is not clear what to do at all. E.g. over usb-2 multiple outstanding commands share the same endpoint. What if a command gets aborted while its sense urb is half way through completing (so some data has been transfered but not all). Since the urb is not yet complete we don't know if the sense urb is actually for this command, or for one of the other oustanding commands. If it is for one of the other commands and we cancel it, then we end up in an undefined state. But if it is actually for the command we're aborting, and the abort succeeds, then it may never complete... This exact same problem applies to logical unit resets too, if there are multiple luns, then commands outstanding on both luns share the sense endpoint. If there is only a single lun, then doing a logical unit reset is little better then doing a full usb device reset. So summarizing because: 1) abort / lun-reset is very tricky to get right 2) Not being able to test the tricky code, which means it will have bugs 3) This being a code path which under normal operation will never happen, so being slow / sub-optimal here is not really an issue 4) Under error conditions we will still be able to recover through usb device resets. 5) This may be a bit slower in some cases, but this is actually faster in cases where the bridge ship has locked up, which seems to be the most common error case sofar. This commit removes the abort / lun-reset error handling paths, and also the taks-mgmt code since those are the only 2 task-mgmt users. Leaving only the (tested and testable) usb-device-reset error handling path in place. Note I realize that this is somewhat of a big hammer, but currently people are seeing very hard to debug oopses with uas. First let focus on making uas work reliable, then we can later look into adding more fine grained error handling. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment