• James.Smart@Emulex.Com's avatar
    [SCSI] update fc_transport for removal of block/unblock functions · 19a7b4ae
    James.Smart@Emulex.Com authored
    We recently went back to implement a board reset. When we perform the
    reset, we wanted to tear down the internal data structures and rebuild
    them. Unfortunately, when it came to the rport structure, things were
    odd. If we deleted them, the scsi targets and sdevs would be
    torn down. Not a good thing for a temporary reset. We could block the
    rports, but we either maintain the internal structures to keep the
    rport reference (perhaps even replicating what's in the transport),
    or we have to fatten the fc transport with new search routines to find
    the rport (and deal with a case of a dangling rport that the driver
    It dawned on me that we had actually reached this state incorrectly.
    When the fc transport first started, we did the block/unblock first, then
    added the rport interface. The purpose of block/unblock is to hide the
    temporary disappearance of the rport (e.g. being deleted, then readded).
    Why are we making the driver do the block/unblock ? We should be making
    the transport have only an rport add/delete, and the let the transport
    handle the block/unblock.
    So... This patch removes the existing fc_remote_port_block/unblock
    functions. It moves the block/unblock functionality into the
    fc_remote_port_add/delete functions.  Updates for the lpfc driver are
    included. Qlogic driver updates are also enclosed, thanks to the
    contributions of Andrew Vasquez. [Note: the qla2xxx changes are
    relative to the scsi-misc-2.6 tree as of this morning - which does
    not include the recent patches sent by Andrew]. The zfcp driver does
    not use the block/unblock functions.
    One last comment: The resulting behavior feels very clean. The LLDD is
    concerned only with add/delete, which corresponds to the physical
    disappearance.  However, the fact that the scsi target and sdevs are
    not immediately torn down after the LLDD calls delete causes an
    interesting scenario... the midlayer can call the xxx_slave_alloc and
    xxx_queuecommand functions with a sdev that is at the location the
    rport used to be. The driver must validate the device exists when it
    first enters these functions. In thinking about it, this has always
    been the case for the LLDD and these routines. The existing drivers
    already check for existence. However, this highlights that simple
    validation via data structure dereferencing needs to be watched.
    To deal with this, a new transport function, fc_remote_port_chkready()
    was created that LLDDs should call when they first enter these two
    routines. It validates the rport state, and returns a scsi result
    which could be returned. In addition to solving the above, it also
    creates consistent behavior from the LLDD's when the block and deletes
    are occuring.
    Rejections fixed up and
    Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
scsi_transport_fc.h 14.8 KB