linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH V3] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert
@ 2018-03-02  3:31 Jianchao Wang
  2018-03-02 16:31 ` Bart Van Assche
  0 siblings, 1 reply; 3+ messages in thread
From: Jianchao Wang @ 2018-03-02  3:31 UTC (permalink / raw)
  To: jejb, martin.petersen
  Cc: Bart.VanAssche, linux-scsi, linux-kernel, Christoph Hellwig

In scsi core, __scsi_queue_insert should just put request back on
the queue and retry using the same command as before. However, for
blk-mq, scsi_mq_requeue_cmd is employed here which will unprepare
the request. To align with the semantics of __scsi_queue_insert,
use blk_mq_requeue_request with kick_requeue_list == true and put
the reference of scsi_device.

Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jianchao Wang <jianchao.w.wang@oracle.com>
Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>

---
Changelog:
V2 -> V3:
 - add commit to explain why we need a put_device in
   __scsi_queue_insert
 - add reviewed-by

V1 -> V2:
 - add put_device on scsi_device->sdev_gendev

 drivers/scsi/scsi_lib.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a86df9c..d2f1838 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -191,7 +191,13 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd, int reason, bool unbusy)
 	 */
 	cmd->result = 0;
 	if (q->mq_ops) {
-		scsi_mq_requeue_cmd(cmd);
+		/*
+		 * scsi_device.sdev_gendev will be get every time in .get_budget and
+		 * be put in scsi_end_request. Hence we need to put the reference
+		 * here when we decide to requeue request.
+		 */
+		blk_mq_requeue_request(cmd->request, true);
+		put_device(&device->sdev_gendev);
 		return;
 	}
 	spin_lock_irqsave(q->queue_lock, flags);
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH V3] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert
  2018-03-02  3:31 [PATCH V3] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert Jianchao Wang
@ 2018-03-02 16:31 ` Bart Van Assche
  2018-03-03  1:41   ` jianchao.wang
  0 siblings, 1 reply; 3+ messages in thread
From: Bart Van Assche @ 2018-03-02 16:31 UTC (permalink / raw)
  To: jejb, martin.petersen, jianchao.w.wang; +Cc: linux-scsi, linux-kernel, hch

On Fri, 2018-03-02 at 11:31 +0800, Jianchao Wang wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index a86df9c..d2f1838 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -191,7 +191,13 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd, int reason, bool unbusy)
>  	 */
>  	cmd->result = 0;
>  	if (q->mq_ops) {
> -		scsi_mq_requeue_cmd(cmd);
> +		/*
> +		 * scsi_device.sdev_gendev will be get every time in .get_budget and
> +		 * be put in scsi_end_request. Hence we need to put the reference
> +		 * here when we decide to requeue request.
> +		 */
> +		blk_mq_requeue_request(cmd->request, true);
> +		put_device(&device->sdev_gendev);
>  		return;
>  	}
>  	spin_lock_irqsave(q->queue_lock, flags);

Please consider to change the new comment into something like the following:
"Before a SCSI command is dispatched, get_device(&sdev->sdev_gendev) is called
and the host, target and device busy counters are increased. Since requeuing a
request causes these actions to be repeated and since scsi_device_unbusy() has
already been called, put_device(&device->sdev_gendev) must still be called. Call
put_device() after blk_mq_requeue_request() to avoid that removal of the SCSI
device can start before requeueing has happened."

Thanks,

Bart.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH V3] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert
  2018-03-02 16:31 ` Bart Van Assche
@ 2018-03-03  1:41   ` jianchao.wang
  0 siblings, 0 replies; 3+ messages in thread
From: jianchao.wang @ 2018-03-03  1:41 UTC (permalink / raw)
  To: Bart Van Assche, jejb, martin.petersen; +Cc: linux-scsi, linux-kernel, hch

Hi Bart

Thanks for your kindly response and directive.

On 03/03/2018 12:31 AM, Bart Van Assche wrote:
> On Fri, 2018-03-02 at 11:31 +0800, Jianchao Wang wrote:
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index a86df9c..d2f1838 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -191,7 +191,13 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd, int reason, bool unbusy)
>>  	 */
>>  	cmd->result = 0;
>>  	if (q->mq_ops) {
>> -		scsi_mq_requeue_cmd(cmd);
>> +		/*
>> +		 * scsi_device.sdev_gendev will be get every time in .get_budget and
>> +		 * be put in scsi_end_request. Hence we need to put the reference
>> +		 * here when we decide to requeue request.
>> +		 */
>> +		blk_mq_requeue_request(cmd->request, true);
>> +		put_device(&device->sdev_gendev);
>>  		return;
>>  	}
>>  	spin_lock_irqsave(q->queue_lock, flags);
> 
> Please consider to change the new comment into something like the following:
> "Before a SCSI command is dispatched, get_device(&sdev->sdev_gendev) is called
> and the host, target and device busy counters are increased. Since requeuing a
> request causes these actions to be repeated and since scsi_device_unbusy() has
> already been called, put_device(&device->sdev_gendev) must still be called. Call
> put_device() after blk_mq_requeue_request() to avoid that removal of the SCSI
> device can start before requeueing has happened."

Yes, your comment is more detailed and clearly.

Sincerely
Jianchao

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-03-03  1:41 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-02  3:31 [PATCH V3] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert Jianchao Wang
2018-03-02 16:31 ` Bart Van Assche
2018-03-03  1:41   ` jianchao.wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).