aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorWei Fang <fangwei1@huawei.com>2016-12-13 09:25:21 +0800
committerMartin K. Petersen <martin.petersen@oracle.com>2016-12-14 15:51:17 -0500
commitd2a145252c52792bc59e4767b486b26c430af4bb (patch)
tree1e863d6cf6fc76ceb9abbbc8e5b70a9d82aa35c6 /Documentation
parentscsi: mpt3sas: Recognize and act on iopriority info (diff)
downloadlinux-dev-d2a145252c52792bc59e4767b486b26c430af4bb.tar.xz
linux-dev-d2a145252c52792bc59e4767b486b26c430af4bb.zip
scsi: avoid a permanent stop of the scsi device's request queue
A race between scanning and fc_remote_port_delete() may result in a permanent stop if the device gets blocked before scsi_sysfs_add_sdev() and unblocked after. The reason is that blocking a device sets both the SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However, scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the device to be ignored by scsi_target_unblock() and thus never have its QUEUE_FLAG_STOPPED cleared leading to a device which is apparently running but has a stopped queue. We actually have two places where SDEV_RUNNING is set: once in scsi_add_lun() which respects the blocked flag and once in scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely spurious, simply remove it to fix the problem. Cc: <stable@vger.kernel.org> Reported-by: Zengxi Chen <chenzengxi@huawei.com> Signed-off-by: Wei Fang <fangwei1@huawei.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions