| Message ID | 20230515070156.1790181-3-haowenchao2@huawei.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Fix kernel panic in scsi_queue_rq() | expand |
On Mon, May 15, 2023 at 03:01:56PM +0800, Wenchao Hao wrote: > If scsi_dispatch_cmd() failed, the SCSI command was not sent to the target, > scsi_queue_rq() would return BLK_STS_RESOURCE and the related request > would be requeued. The timeout of this request would not fire, no one would > increase iodone_cnt. > > The above flow would result the iodone_cnt smaller than iorequest_cnt. > So decrease the iorequest_cnt if dispatch failed to workaround the issue. > > Link:https://lore.kernel.org/linux-scsi/8e0f2d31-e6ff-ec4a-3974-450560ad49c5@huawei.com/T/#t > > Signed-off-by: Wenchao Hao <haowenchao2@huawei.com> > --- > drivers/scsi/scsi_lib.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index 03964b26f3f2..0226c9279cef 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -1485,6 +1485,7 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd) > */ > SCSI_LOG_MLQUEUE(3, scmd_printk(KERN_INFO, cmd, > "queuecommand : device blocked\n")); > + atomic_dec(&cmd->device->iorequest_cnt); > return SCSI_MLQUEUE_DEVICE_BUSY; > } > > @@ -1517,6 +1518,7 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd) > trace_scsi_dispatch_cmd_start(cmd); > rtn = host->hostt->queuecommand(host, cmd); > if (rtn) { > + atomic_dec(&cmd->device->iorequest_cnt); > trace_scsi_dispatch_cmd_error(cmd, rtn); > if (rtn != SCSI_MLQUEUE_DEVICE_BUSY && > rtn != SCSI_MLQUEUE_TARGET_BUSY) Looks fine, so the command is accounted in case that it is consumed by scsi stack, otherwise the counter has to be undone. Reviewed-by: Ming Lei <ming.lei@redhat.com> Thanks, Ming
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 03964b26f3f2..0226c9279cef 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1485,6 +1485,7 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd) */ SCSI_LOG_MLQUEUE(3, scmd_printk(KERN_INFO, cmd, "queuecommand : device blocked\n")); + atomic_dec(&cmd->device->iorequest_cnt); return SCSI_MLQUEUE_DEVICE_BUSY; } @@ -1517,6 +1518,7 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd) trace_scsi_dispatch_cmd_start(cmd); rtn = host->hostt->queuecommand(host, cmd); if (rtn) { + atomic_dec(&cmd->device->iorequest_cnt); trace_scsi_dispatch_cmd_error(cmd, rtn); if (rtn != SCSI_MLQUEUE_DEVICE_BUSY && rtn != SCSI_MLQUEUE_TARGET_BUSY)
If scsi_dispatch_cmd() failed, the SCSI command was not sent to the target, scsi_queue_rq() would return BLK_STS_RESOURCE and the related request would be requeued. The timeout of this request would not fire, no one would increase iodone_cnt. The above flow would result the iodone_cnt smaller than iorequest_cnt. So decrease the iorequest_cnt if dispatch failed to workaround the issue. Link:https://lore.kernel.org/linux-scsi/8e0f2d31-e6ff-ec4a-3974-450560ad49c5@huawei.com/T/#t Signed-off-by: Wenchao Hao <haowenchao2@huawei.com> --- drivers/scsi/scsi_lib.c | 2 ++ 1 file changed, 2 insertions(+)