From: Ming Lei <ming.lei@redhat.com> To: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org, Hannes Reinecke <hare@suse.com>, Keith Busch <keith.busch@intel.com>, linux-nvme@lists.infradead.org, Sagi Grimberg <sagi@grimberg.me>, Ming Lei <ming.lei@redhat.com>, Dongli Zhang <dongli.zhang@oracle.com>, James Smart <james.smart@broadcom.com>, Bart Van Assche <bart.vanassche@wdc.com>, linux-scsi@vger.kernel.org, "Martin K . Petersen" <martin.petersen@oracle.com>, Christoph Hellwig <hch@lst.de>, "James E . J . Bottomley" <jejb@linux.vnet.ibm.com>, jianchao wang <jianchao.w.wang@oracle.com> Subject: [PATCH V6 2/9] blk-mq: move cancel of requeue_work into blk_mq_release Date: Wed, 17 Apr 2019 11:44:03 +0800 [thread overview] Message-ID: <20190417034410.31957-3-ming.lei@redhat.com> (raw) In-Reply-To: <20190417034410.31957-1-ming.lei@redhat.com> 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> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> 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 a55389ba8779..93dc588fabe2 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 ef5a16a2d6fb..55776a6e2586 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2640,6 +2640,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) -- 2.9.5
WARNING: multiple messages have this Message-ID (diff)
From: ming.lei@redhat.com (Ming Lei) Subject: [PATCH V6 2/9] blk-mq: move cancel of requeue_work into blk_mq_release Date: Wed, 17 Apr 2019 11:44:03 +0800 [thread overview] Message-ID: <20190417034410.31957-3-ming.lei@redhat.com> (raw) In-Reply-To: <20190417034410.31957-1-ming.lei@redhat.com> 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 at oracle.com> Cc: James Smart <james.smart at broadcom.com> Cc: Bart Van Assche <bart.vanassche at wdc.com> Cc: linux-scsi at vger.kernel.org, Cc: Martin K . Petersen <martin.petersen at oracle.com>, Cc: Christoph Hellwig <hch at lst.de>, Cc: James E . J . Bottomley <jejb at linux.vnet.ibm.com>, Cc: jianchao wang <jianchao.w.wang at oracle.com> Reviewed-by: Bart Van Assche <bvanassche at acm.org> Reviewed-by: Johannes Thumshirn <jthumshirn at suse.de> Signed-off-by: Ming Lei <ming.lei at 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 a55389ba8779..93dc588fabe2 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 ef5a16a2d6fb..55776a6e2586 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2640,6 +2640,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) -- 2.9.5
next prev parent reply other threads:[~2019-04-17 3:44 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-17 3:44 [PATCH V6 0/9] blk-mq: fix races related with freeing queue Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 3:44 ` [PATCH V6 1/9] blk-mq: grab .q_usage_counter when queuing request from plug code path Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 3:44 ` Ming Lei [this message] 2019-04-17 3:44 ` [PATCH V6 2/9] blk-mq: move cancel of requeue_work into blk_mq_release Ming Lei 2019-04-17 12:00 ` Hannes Reinecke 2019-04-17 12:00 ` Hannes Reinecke 2019-04-17 3:44 ` [PATCH V6 3/9] blk-mq: free hw queue's resource in hctx's release handler Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 12:02 ` Hannes Reinecke 2019-04-17 12:02 ` Hannes Reinecke 2019-04-17 3:44 ` [PATCH V6 4/9] blk-mq: move all hctx alloction & initialization into __blk_mq_alloc_and_init_hctx Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 12:03 ` Hannes Reinecke 2019-04-17 12:03 ` Hannes Reinecke 2019-04-17 3:44 ` [PATCH V6 5/9] blk-mq: split blk_mq_alloc_and_init_hctx into two parts Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 3:44 ` [PATCH V6 6/9] blk-mq: always free hctx after request queue is freed Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 12:08 ` Hannes Reinecke 2019-04-17 12:08 ` Hannes Reinecke 2019-04-17 12:59 ` Ming Lei 2019-04-17 12:59 ` Ming Lei 2019-04-22 3:30 ` Ming Lei 2019-04-22 3:30 ` Ming Lei 2019-04-23 11:19 ` Hannes Reinecke 2019-04-23 11:19 ` Hannes Reinecke 2019-04-23 13:30 ` Ming Lei 2019-04-23 13:30 ` Ming Lei 2019-04-23 14:07 ` Hannes Reinecke 2019-04-23 14:07 ` Hannes Reinecke 2019-04-24 1:12 ` Ming Lei 2019-04-24 1:12 ` Ming Lei 2019-04-24 1:45 ` Ming Lei 2019-04-24 1:45 ` Ming Lei 2019-04-24 5:55 ` Hannes Reinecke 2019-04-24 5:55 ` Hannes Reinecke 2019-04-17 3:44 ` [PATCH V6 7/9] blk-mq: move cancel of hctx->run_work into blk_mq_hw_sysfs_release Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 3:44 ` [PATCH V6 8/9] block: don't drain in-progress dispatch in blk_cleanup_queue() Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 3:44 ` [PATCH V6 9/9] nvme: hold request queue's refcount in ns's whole lifetime Ming Lei 2019-04-17 3:44 ` Ming Lei 2019-04-17 12:10 ` Hannes Reinecke 2019-04-17 12:10 ` Hannes Reinecke 2019-04-17 15:55 ` Keith Busch 2019-04-17 15:55 ` Keith Busch 2019-04-17 17:22 ` [PATCH V6 0/9] blk-mq: fix races related with freeing queue James Smart 2019-04-17 17:22 ` James Smart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190417034410.31957-3-ming.lei@redhat.com \ --to=ming.lei@redhat.com \ --cc=axboe@kernel.dk \ --cc=bart.vanassche@wdc.com \ --cc=dongli.zhang@oracle.com \ --cc=hare@suse.com \ --cc=hch@lst.de \ --cc=james.smart@broadcom.com \ --cc=jejb@linux.vnet.ibm.com \ --cc=jianchao.w.wang@oracle.com \ --cc=keith.busch@intel.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=sagi@grimberg.me \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.