summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorWei Fang <fangwei1@huawei.com>2016-12-13 09:25:21 +0800
committerSasha Levin <alexander.levin@verizon.com>2017-01-12 20:56:57 -0500
commit1b51fce881b201cc00e88f64357d61b067e6b588 (patch)
tree978a6ccbc058dfc264f85b03c8c2f981ed29ca4f /kernel
parentf413092ea8e0c838c784abfcbd927d44ee6d01c7 (diff)
scsi: avoid a permanent stop of the scsi device's request queue
[ Upstream commit d2a145252c52792bc59e4767b486b26c430af4bb ] 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> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions