[PATCH] fix scsi cmnd retries in error handling

[PATCH] fix scsi cmnd retries in error handling

[Hillf Danton]

There are two instances of increment and test of retries of scsi cmnd
in functions scsi_decide_disposition() and scsi_eh_flush_done_q()
respectively.

One of the increments is overwork when the corresponding cmnds are same.
The overwork is fixed in scsi_decide_disposition().

Signed-off-by: Hillf Danton <dhillf@gmail.com>
---

--- a/drivers/scsi/scsi_error.c	2010-09-13 07:07:38.000000000 +0800
+++ b/drivers/scsi/scsi_error.c	2010-11-01 20:39:38.000000000 +0800
@@ -1541,7 +1541,7 @@ int scsi_decide_disposition(struct scsi_
 	 * the request was not marked fast fail.  Note that above,
 	 * even if the request is marked fast fail, we still requeue
 	 * for queue congestion conditions (QUEUE_FULL or BUSY) */
-	if ((++scmd->retries) <= scmd->allowed
+	if (scmd->retries < scmd->allowed
 	    && !scsi_noretry_cmd(scmd)) {
 		return NEEDS_RETRY;
 	} else {

Re: [PATCH] fix scsi cmnd retries in error handling

[James Bottomley]

On Mon, 2010-11-01 at 21:02 +0800, Hillf Danton wrote:
> There are two instances of increment and test of retries of scsi cmnd
> in functions scsi_decide_disposition() and scsi_eh_flush_done_q()
> respectively.

This analysis is incomplete.  Those two functions are called in
completely separate paths, so you can't remove the increment from one
and expect the other to compensate.

James

> One of the increments is overwork when the corresponding cmnds are same.
> The overwork is fixed in scsi_decide_disposition().
> 
> Signed-off-by: Hillf Danton <dhillf@gmail.com>
> ---
> 
> --- a/drivers/scsi/scsi_error.c	2010-09-13 07:07:38.000000000 +0800
> +++ b/drivers/scsi/scsi_error.c	2010-11-01 20:39:38.000000000 +0800
> @@ -1541,7 +1541,7 @@ int scsi_decide_disposition(struct scsi_
>  	 * the request was not marked fast fail.  Note that above,
>  	 * even if the request is marked fast fail, we still requeue
>  	 * for queue congestion conditions (QUEUE_FULL or BUSY) */
> -	if ((++scmd->retries) <= scmd->allowed
> +	if (scmd->retries < scmd->allowed
>  	    && !scsi_noretry_cmd(scmd)) {
>  		return NEEDS_RETRY;
>  	} else {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fix scsi cmnd retries in error handling

[Hillf Danton]

On Mon, Nov 1, 2010 at 9:38 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> On Mon, 2010-11-01 at 21:02 +0800, Hillf Danton wrote:
>> There are two instances of increment and test of retries of scsi cmnd
>> in functions scsi_decide_disposition() and scsi_eh_flush_done_q()
>> respectively.
>
> This analysis is incomplete.  Those two functions are called in

Though incomplete, there is chance they could be threaded up by
scsi_unjam_host(). //Hillf

> completely separate paths, so you can't remove the increment from one
> and expect the other to compensate.
>
> James
>
>> One of the increments is overwork when the corresponding cmnds are same.
>> The overwork is fixed in scsi_decide_disposition().
>>
>> Signed-off-by: Hillf Danton <dhillf@gmail.com>
>> ---
>>
>> --- a/drivers/scsi/scsi_error.c       2010-09-13 07:07:38.000000000 +0800
>> +++ b/drivers/scsi/scsi_error.c       2010-11-01 20:39:38.000000000 +0800
>> @@ -1541,7 +1541,7 @@ int scsi_decide_disposition(struct scsi_
>>        * the request was not marked fast fail.  Note that above,
>>        * even if the request is marked fast fail, we still requeue
>>        * for queue congestion conditions (QUEUE_FULL or BUSY) */
>> -     if ((++scmd->retries) <= scmd->allowed
>> +     if (scmd->retries < scmd->allowed
>>           && !scsi_noretry_cmd(scmd)) {
>>               return NEEDS_RETRY;
>>       } else {
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fix scsi cmnd retries in error handling

[Hillf Danton]

On Mon, Nov 1, 2010 at 9:38 PM, James Bottomley <James.Bottomley@suse.de> wrote:
> On Mon, 2010-11-01 at 21:02 +0800, Hillf Danton wrote:
>> There are two instances of increment and test of retries of scsi cmnd
>> in functions scsi_decide_disposition() and scsi_eh_flush_done_q()
>> respectively.
>
> This analysis is incomplete.  Those two functions are called in
> completely separate paths, so you can't remove the increment from one
> and expect the other to compensate.
>

The delivered is not correct, and it could get fixed.


--- a/drivers/scsi/scsi_error.c	2010-11-01 19:54:12.000000000 +0800
+++ b/drivers/scsi/scsi_error.c	2010-12-01 21:55:52.000000000 +0800
@@ -927,6 +927,13 @@ int scsi_eh_get_sense(struct list_head *
 			scmd->retries = scmd->allowed;
 		else if (rtn != NEEDS_RETRY)
 			continue;
+		else if (host_byte(scmd->result) != DID_IMM_RETRY)
+			/*
+			 * in case of NEEDS_RETRY, undo the increment of
+			 * retries in scsi_decide_disposition() since it
+			 * is also checked when flushing done_q.
+			 */
+			scmd->retries--;

 		scsi_eh_finish_cmd(scmd, done_q);
 	}



But there is still room for simplification,

--- a/drivers/scsi/scsi_error.c	2010-11-01 19:54:12.000000000 +0800
+++ b/drivers/scsi/scsi_error.c	2010-12-01 22:08:34.000000000 +0800
@@ -896,6 +896,8 @@ int scsi_eh_get_sense(struct list_head *
 	struct scsi_cmnd *scmd, *next;
 	int rtn;

+	return list_empty(work_q);
+
 	list_for_each_entry_safe(scmd, next, work_q, eh_entry) {
 		if ((scmd->eh_eflags & SCSI_EH_CANCEL_CMD) ||
 		    SCSI_SENSE_VALID(scmd))


since SCSI_EH_CANCEL_CMD is concerned not only by scsi_eh_scmd_add() but by
scsi_eh_get_sense() also, which looks a reasonable explanation to what
they are called in
completely separate paths.

Thanks
Hillf


> James
>
>> One of the increments is overwork when the corresponding cmnds are same.
>> The overwork is fixed in scsi_decide_disposition().
>>
>> Signed-off-by: Hillf Danton <dhillf@gmail.com>
>> ---
>>
>> --- a/drivers/scsi/scsi_error.c       2010-09-13 07:07:38.000000000 +0800
>> +++ b/drivers/scsi/scsi_error.c       2010-11-01 20:39:38.000000000 +0800
>> @@ -1541,7 +1541,7 @@ int scsi_decide_disposition(struct scsi_
>>        * the request was not marked fast fail.  Note that above,
>>        * even if the request is marked fast fail, we still requeue
>>        * for queue congestion conditions (QUEUE_FULL or BUSY) */
>> -     if ((++scmd->retries) <= scmd->allowed
>> +     if (scmd->retries < scmd->allowed
>>           && !scsi_noretry_cmd(scmd)) {
>>               return NEEDS_RETRY;
>>       } else {
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html