summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/ibmvscsi
diff options
context:
space:
mode:
authorRobert Jennings <rcj@linux.vnet.ibm.com>2007-10-30 11:37:07 -0500
committerJames Bottomley <James.Bottomley@HansenPartnership.com>2007-11-03 12:10:36 -0500
commit3c887e8a1a4553ae6263fc9490e33de213e3746f (patch)
tree38cf13ce92acd4740a74b12a37808650c83edca3 /drivers/scsi/ibmvscsi
parent7e2b19fbc7b9c1fd8ee9c79b375fcedb69dd07c9 (diff)
downloadop-kernel-dev-3c887e8a1a4553ae6263fc9490e33de213e3746f.zip
op-kernel-dev-3c887e8a1a4553ae6263fc9490e33de213e3746f.tar.gz
[SCSI] ibmvscsi: Prevent IO during partner login
By setting the request_limit in send_srp_login to 1 we allowed login requests to be sent to the server adapter. If this was not an initial login, but was a login after a disconnect with the server, other I/O requests could attempt to be processed before the login occured. These I/O requests would fail, sometimes resulting in filesystems getting marked read-only. To address this we can set the request_limit to 0 while doing the login and add an exception where login requests, along with task management events, are always passed to the server. There is a case where the request_limit had already reached 0 would result in all events being sent rather than returning SCSI_MLQUEUE_HOST_BUSY; this has also been fixed by this patch. Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com> Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Diffstat (limited to 'drivers/scsi/ibmvscsi')
-rw-r--r--drivers/scsi/ibmvscsi/ibmvscsi.c19
1 files changed, 14 insertions, 5 deletions
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index 22d91ee..5f2396c 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -556,7 +556,7 @@ static int ibmvscsi_send_srp_event(struct srp_event_struct *evt_struct,
unsigned long timeout)
{
u64 *crq_as_u64 = (u64 *) &evt_struct->crq;
- int request_status;
+ int request_status = 0;
int rc;
/* If we have exhausted our request limit, just fail this request,
@@ -574,6 +574,13 @@ static int ibmvscsi_send_srp_event(struct srp_event_struct *evt_struct,
if (request_status < -1)
goto send_error;
/* Otherwise, we may have run out of requests. */
+ /* If request limit was 0 when we started the adapter is in the
+ * process of performing a login with the server adapter, or
+ * we may have run out of requests.
+ */
+ else if (request_status == -1 &&
+ evt_struct->iu.srp.login_req.opcode != SRP_LOGIN_REQ)
+ goto send_busy;
/* Abort and reset calls should make it through.
* Nothing except abort and reset should use the last two
* slots unless we had two or less to begin with.
@@ -633,7 +640,8 @@ static int ibmvscsi_send_srp_event(struct srp_event_struct *evt_struct,
unmap_cmd_data(&evt_struct->iu.srp.cmd, evt_struct, hostdata->dev);
free_event_struct(&hostdata->pool, evt_struct);
- atomic_inc(&hostdata->request_limit);
+ if (request_status != -1)
+ atomic_inc(&hostdata->request_limit);
return SCSI_MLQUEUE_HOST_BUSY;
send_error:
@@ -927,10 +935,11 @@ static int send_srp_login(struct ibmvscsi_host_data *hostdata)
login->req_buf_fmt = SRP_BUF_FORMAT_DIRECT | SRP_BUF_FORMAT_INDIRECT;
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
+ /* Start out with a request limit of 0, since this is negotiated in
+ * the login request we are just sending and login requests always
+ * get sent by the driver regardless of request_limit.
*/
- atomic_set(&hostdata->request_limit, 1);
+ atomic_set(&hostdata->request_limit, 0);
rc = ibmvscsi_send_srp_event(evt_struct, hostdata, init_timeout * 2);
spin_unlock_irqrestore(hostdata->host->host_lock, flags);
OpenPOWER on IntegriCloud