Re: [PATCH V3 2/6] blk-mq: move cancel of requeue_work into blk_mq_release

[Bart Van Assche <bvanassche@acm.org>]

On Wed, 2019-04-03 at 18:26 +0800, Ming Lei wrote:
> with holding queue's kobject refcount, it is safe for driver
> to schedule requeue. However, blk_mq_kick_requeue_list() may
> be called after blk_sync_queue() is done because of concurrent
> requeue activities, then requeue work may not be completed when
> freeing queue, and kernel oops is triggered.
> 
> So moving the cancel of requeue_work into blk_mq_release() for
> avoiding race between requeue and freeing queue.
> 
> Cc: Dongli Zhang <dongli.zhang@oracle.com>
> Cc: James Smart <james.smart@broadcom.com>
> Cc: Bart Van Assche <bart.vanassche@wdc.com>
> Cc: linux-scsi@vger.kernel.org,
> Cc: Martin K . Petersen <martin.petersen@oracle.com>,
> Cc: Christoph Hellwig <hch@lst.de>,
> Cc: James E . J . Bottomley <jejb@linux.vnet.ibm.com>,
> Cc: jianchao wang <jianchao.w.wang@oracle.com>
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
>
>  block/blk-core.c | 1 -
>  block/blk-mq.c   | 2 ++
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 4673ebe42255..6583d67f3e34 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -237,7 +237,6 @@ void blk_sync_queue(struct request_queue *q)
>                 struct blk_mq_hw_ctx *hctx;
>                 int i;
>  
> -               cancel_delayed_work_sync(&q->requeue_work);
>                 queue_for_each_hw_ctx(q, hctx, i)
>                         cancel_delayed_work_sync(&hctx->run_work);
>         }
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 5b586affee09..b512ba0cb359 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -2626,6 +2626,8 @@ void blk_mq_release(struct request_queue *q)
>         struct blk_mq_hw_ctx *hctx;
>         unsigned int i;
>  
> +       cancel_delayed_work_sync(&q->requeue_work);
> +
>         /* hctx kobj stays in hctx */
>         queue_for_each_hw_ctx(q, hctx, i) {
>                 if (!hctx)

Reviewed-by: Bart Van Assche <bvanassche@acm.org>