Message ID | 20221021235638.1968832-2-haowenchao@huawei.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Fix scsi device's iodone_cnt mismatch with iorequest_cnt | expand |
On 10/21/22 6:56 PM, Wenchao Hao wrote: > If an scsi command time out and going to be aborted, we should > increase the iodone_cnt of the related scsi device, or the > iodone_cnt would be less than iorequest_cnt > > Increase iodone_cnt in scsi_timeout() would not cause double > accounting issue, briefly analysed as following: > > - we add the iodone_cnt when BLK_EH_DONE would be returned in > scsi_timeout(), so the related scsi command's timeout event > would not happened > > - if the abort succeed and do not retry, the command would be done > with scsi_finish_command() which would not increase iodone_cnt; > > - if the abort succeed and retry the command, it would be requeue, > a scsi_dispatch_cmd() would be called and iorequest_cnt would be > increased again > > - if the abort failed, the error handler successfully recover the > device, do not retry this command, the command would be done > with scsi_finish_command() which would not increase iodone_cnt; > > - if the abort failed, the error handler successfully recover the > device, and retry this command, the iorequest_cnt would be > increased again > > Signed-off-by: Wenchao Hao <haowenchao@huawei.com> > --- > drivers/scsi/scsi_error.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > index 6995c8979230..052b00f57b56 100644 > --- a/drivers/scsi/scsi_error.c > +++ b/drivers/scsi/scsi_error.c > @@ -356,6 +356,7 @@ enum blk_eh_timer_return scsi_timeout(struct request *req) > */ > if (test_and_set_bit(SCMD_STATE_COMPLETE, &scmd->state)) > return BLK_EH_RESET_TIMER; You will need to rebase this patch because the above line is different now so it doesn't apply. It looks ok to me though. Reviewed-by: Mike Christie <michael.christie@oracle.com> > + atomic_inc(&scmd->device->iodone_cnt); > if (scsi_abort_command(scmd) != SUCCESS) { > set_host_byte(scmd, DID_TIME_OUT); > scsi_eh_scmd_add(scmd);
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 6995c8979230..052b00f57b56 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -356,6 +356,7 @@ enum blk_eh_timer_return scsi_timeout(struct request *req) */ if (test_and_set_bit(SCMD_STATE_COMPLETE, &scmd->state)) return BLK_EH_RESET_TIMER; + atomic_inc(&scmd->device->iodone_cnt); if (scsi_abort_command(scmd) != SUCCESS) { set_host_byte(scmd, DID_TIME_OUT); scsi_eh_scmd_add(scmd);
If an scsi command time out and going to be aborted, we should increase the iodone_cnt of the related scsi device, or the iodone_cnt would be less than iorequest_cnt Increase iodone_cnt in scsi_timeout() would not cause double accounting issue, briefly analysed as following: - we add the iodone_cnt when BLK_EH_DONE would be returned in scsi_timeout(), so the related scsi command's timeout event would not happened - if the abort succeed and do not retry, the command would be done with scsi_finish_command() which would not increase iodone_cnt; - if the abort succeed and retry the command, it would be requeue, a scsi_dispatch_cmd() would be called and iorequest_cnt would be increased again - if the abort failed, the error handler successfully recover the device, do not retry this command, the command would be done with scsi_finish_command() which would not increase iodone_cnt; - if the abort failed, the error handler successfully recover the device, and retry this command, the iorequest_cnt would be increased again Signed-off-by: Wenchao Hao <haowenchao@huawei.com> --- drivers/scsi/scsi_error.c | 1 + 1 file changed, 1 insertion(+)