Sounds reasonable... Only change I'd make is rather than comparing all the
different states, simply compare (rport->port_state != FC_PORTSTATE_ONLINE)
-- james s
Hannes Reinecke wrote:
Hi James (& James, too :-),
scsi_transport_fc.c:fc_user_scan() should check the portstates prior to
calling scsi_scan_target(). Otherwise we might get a nice oops as the
rport might already been disconnected from the host by the time we're
calling scsi_scan_target(). Thus the traversal from the rport to the
scsi_host in scsi_scan_target() will fail, resulting in a nice Oops.
Plus it's quite pointless to scan a target if the portstates already
told us that we can't communicate with it.
Please apply.
Cheers,
Hannes
------------------------------------------------------------------------
scsi_transport_fc: Check portstates before invoking target scan
When a target scan is initiated from sysfs, we should check the
portstate prior to invoke scsi_scan_target().
Otherwise scsi_scan_target() might oops as the rport might already
been removed from the scsi host and the traversal from the rport to
the scsi_host in scsi_scan_target() will fail.
Also the portstate already told us that communication with the target
has failed, so it's quite pointless to try.
Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 4953f0d..bd73615 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -1943,6 +1943,12 @@ static int fc_user_scan(struct Scsi_Host
if (rport->scsi_target_id == -1)
continue;
+ if ((rport->port_state == FC_PORTSTATE_NOTPRESENT) ||
+ (rport->port_state == FC_PORTSTATE_UNKNOWN) ||
+ (rport->port_state == FC_PORTSTATE_DELETED) ||
+ (rport->port_state == FC_PORTSTATE_BLOCKED))
+ continue;
+
if ((channel == SCAN_WILD_CARD || channel == rport->channel) &&
(id == SCAN_WILD_CARD || id == rport->scsi_target_id)) {
scsi_scan_target(&rport->dev, rport->channel,
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
