Re: [PATCH 2/5] zfcp: Fix deadlock between zfcp ERP and SCSI

[Christof Schmitt <christof.schmitt@de.ibm.com>]

On Tue, May 08, 2007 at 11:00:11AM -0400, James Smart wrote:
> Curious why you are calling scsi_scan_target() or
> scsi_target_block()/scsi_target_unblock() directly. I would have
> thought the add/remove rport code would have done this for you,
> and it deals with all the flush conditions, etc.

fc_remote_port_add issues a scsi_scan_target with SCAN_WILD_CARD. This tries to
get all LUNs for the target via REPORT LUNS for LUN 0. The current design for
zfcp is to prevent the wildcard scan from the SCSI layer by not allocating a
device for LUN 0. When a FCP adapter does not support NPIV, the adapter can
still be shared among multiple Linux systems. Each Linux system can access
different LUNs, that are activated manually via sysfs. So, the wildcard scan
from the FC transport class does nothing and zfcp activates the LUNs it wants
to use via direct calls to scsi_scan_target. If every adapter would support
NPIV, zfcp could rely on the scan by the FC transport class, unfortunately,
this is not the case.

Christof Schmitt