summaryrefslogtreecommitdiffstats
path: root/Documentation/s390
diff options
context:
space:
mode:
authorEJ Hsu <ejh@nvidia.com>2020-01-30 01:25:06 -0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-02-10 11:08:30 -0800
commit3e99862c05a9caa5a27969f41566b428696f5a9a (patch)
treeee47e0fea70a2c965e2bb1e6b9e9f704be123dc9 /Documentation/s390
parentdddb40e83038ec72533b1b5721831caf90224a09 (diff)
downloadlinux-3e99862c05a9caa5a27969f41566b428696f5a9a.tar.bz2
usb: uas: fix a plug & unplug racing
When a uas disk is plugged into an external hub, uas_probe() will be called by the hub thread to do the probe. It will first create a SCSI host and then do the scan for this host. During the scan, it will probe the LUN using SCSI INQUERY command which will be packed in the URB and submitted to uas disk. There might be a chance that this external hub with uas disk attached is unplugged during the scan. In this case, uas driver will fail to submit the URB (due to the NOTATTACHED state of uas device) and try to put this SCSI command back to request queue waiting for next chance to run. In normal case, this cycle will terminate when hub thread gets disconnection event and calls into uas_disconnect() accordingly. But in this case, uas_disconnect() will not be called because hub thread of external hub gets stuck waiting for the completion of this SCSI command. A deadlock happened. In this fix, uas will call scsi_scan_host() asynchronously to avoid the blocking of hub thread. Signed-off-by: EJ Hsu <ejh@nvidia.com> Acked-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200130092506.102760-1-ejh@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/s390')
0 files changed, 0 insertions, 0 deletions