diff options
author | Robert Jennings <rcj@linux.vnet.ibm.com> | 2007-10-30 11:37:07 -0500 |
---|---|---|
committer | James Bottomley <James.Bottomley@HansenPartnership.com> | 2007-11-03 12:10:36 -0500 |
commit | 3c887e8a1a4553ae6263fc9490e33de213e3746f (patch) | |
tree | 38cf13ce92acd4740a74b12a37808650c83edca3 /drivers/scsi/ibmvscsi | |
parent | 7e2b19fbc7b9c1fd8ee9c79b375fcedb69dd07c9 (diff) | |
download | op-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.c | 19 |
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); |