summaryrefslogtreecommitdiffstats
path: root/drivers/s390/scsi/zfcp_qdio.c
diff options
context:
space:
mode:
authorChristof Schmitt <christof.schmitt@de.ibm.com>2007-05-08 11:16:52 +0200
committerJames Bottomley <jejb@mulgrave.il.steeleye.com>2007-05-08 11:55:33 -0500
commit5f852be9e11d62223ea063f6ceed4f9677f54051 (patch)
tree55552b19035695b23329db2b5f03fc7592412b56 /drivers/s390/scsi/zfcp_qdio.c
parent801e0ced1891a2b8cad1a435c45234a719b3b6bf (diff)
downloadtalos-op-linux-5f852be9e11d62223ea063f6ceed4f9677f54051.tar.gz
talos-op-linux-5f852be9e11d62223ea063f6ceed4f9677f54051.zip
[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI
The SCSI stack requires low level drivers to register and unregister devices. For zfcp this leads to the situation where zfcp calls the SCSI stack, the SCSI tries to scan the new device and the scan SCSI command fails. This would require the zfcp erp, but the erp thread is already blocked in the register call. The fix is to make sure that the calls from the ERP thread to the SCSI stack do not block the ERP thread. In detail: 1) Use a workqueue to avoid blocking of the scsi_scan_target calls. 2) When removing a unit make sure that no scsi_scan_target call is pending. 3) Replace scsi_flush_work with scsi_target_unblock. This avoids blocking and has the same result. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'drivers/s390/scsi/zfcp_qdio.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud