There is a window where we can be re-enabling an adapter, but
still allow SCSI commands to be sent to the target. This fix
sets our window (request_limit) to -1 as soon as we know the
adapter is being reenabled, and closes a very teeny tiny
window where we could set the window back to 1 before we
grab a lock.
Signed-off-by: Dave Boutcher <sleddog@xxxxxxxxxx>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
80a091aa369a57350c0496cb6c1594e5833ade6c
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index eaefedd..a279d0a 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -853,14 +853,15 @@ static int send_srp_login(struct ibmvscs
login->max_requested_initiator_to_target_iulen = sizeof(union srp_iu);
login->required_buffer_formats = 0x0006;
+ spin_lock_irqsave(hostdata->host->host_lock, flags);
/* Start out with a request limit of 1, since this is negotiated in
* the login request we are just sending
*/
atomic_set(&hostdata->request_limit, 1);
- spin_lock_irqsave(hostdata->host->host_lock, flags);
rc = ibmvscsi_send_srp_event(evt_struct, hostdata);
spin_unlock_irqrestore(hostdata->host->host_lock, flags);
+ printk("ibmvscsic: sent SRP login\n");
return rc;
};
@@ -1179,6 +1180,7 @@ void ibmvscsi_handle_crq(struct viosrp_c
/* We need to re-setup the interpartition connection */
printk(KERN_INFO
"ibmvscsi: Re-enabling adapter!\n");
+ atomic_set(&hostdata->request_limit, -1);
purge_requests(hostdata, DID_REQUEUE);
if (ibmvscsi_reenable_crq_queue(&hostdata->queue,
hostdata) == 0)
--
1.2.4.gc98264
--
Dave Boutcher
-
: 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
