* Re: [PATCH] fix scsi cmnd retries in error handling
2010-11-01 13:38 ` James Bottomley
@ 2010-11-01 13:53 ` Hillf Danton
2010-12-01 14:09 ` Hillf Danton
1 sibling, 0 replies; 4+ messages in thread
From: Hillf Danton @ 2010-11-01 13:53 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] fix scsi cmnd retries in error handling
2010-11-01 13:38 ` James Bottomley
2010-11-01 13:53 ` Hillf Danton
@ 2010-12-01 14:09 ` Hillf Danton
1 sibling, 0 replies; 4+ messages in thread
From: Hillf Danton @ 2010-12-01 14:09 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 4+ messages in thread