On 07/27/2010 04:32 PM, Vasu Dev wrote:
This isn't one of those races where you are blocking the rport, but the
IO keeps coming around so the retries are used really quickly right (the
driver looks like it has the fc class and internal state checks to
prevent this but I wanted to make sure).
I think I am hitting the above problem.
This tiny time windows can be further reduced by use of wmb() on rport
state change to block and lport getting out of ready since their states
are checked w/o lock in queuecommand path.
I think you need something like this for the lport queue ready check.
It looks like the initial failure from __fc_linkdown->fc_fcp_cleanup
burned a timeout. Then because it missed the lport ready check, it will
use an extra retry just sitting there timing out.
For the rport state check, I think you are supposed to call the fc
chkready function under the host lock. The port state and flags are set
under it. I did the attached patch for that.
libfc: call fc_remote_port_chkready under the host lock.
The rport port state and flags are set under the host lock,
so this patch calls fc_remote_port_chkready with the host lock
held like is also done in the other fc drivers.
Signed-off-by: Mike Christie <michaelc@xxxxxxxxxxx>
diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index eac4d09..a116846 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -1765,14 +1768,14 @@ int fc_queuecommand(struct scsi_cmnd *sc_cmd, void (*done)(struct scsi_cmnd *))
struct fcoe_dev_stats *stats;
lport = shost_priv(sc_cmd->device->host);
- spin_unlock_irq(lport->host->host_lock);
rval = fc_remote_port_chkready(rport);
if (rval) {
sc_cmd->result = rval;
done(sc_cmd);
- goto out;
+ return 0;
}
+ spin_unlock_irq(lport->host->host_lock);
if (!*(struct fc_remote_port **)rport->dd_data) {
/*
