diff for duplicates of <1496167761.2627.22.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index b5efd96..2d6dc6e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,57 +1,51 @@ -On Tue, 2017-05-30 at 13:55 -0400, Keith Busch wrote: -> On Tue, May 30, 2017 at 02:00:44PM -0300, Gabriel Krisman Bertazi wrote: +On Tue, 2017-05-30@13:55 -0400, Keith Busch wrote: +> On Tue, May 30, 2017@02:00:44PM -0300, Gabriel Krisman Bertazi wrote: > > Since the merge window for 4.12, one of the machines in Intel's CI -> > started to hit the WARN_ON below at blk_mq_update_nr_hw_queues during a= -n +> > started to hit the WARN_ON below at blk_mq_update_nr_hw_queues during an > > nvme_reset_work. The issue persists with the latest 4.12-rc3, and full > > dmesg from boot, up to the moment where the WARN_ON triggers is > > available at the following link: -> >=20 -> > https://intel-gfx-ci.01.org/CI/CI_DRM_2672/fi-kbl-7500u/igt@kms_pipe_cr= -c_basic@suspend-read-crc-pipe-a.html -> >=20 +> > +> > https://intel-gfx-ci.01.org/CI/CI_DRM_2672/fi-kbl-7500u/igt at kms_pipe_crc_basic@suspend-read-crc-pipe-a.html +> > > > Please notice that the test we do in the CI involves putting the > > machine to sleep (PM), and the issue triggers when resuming execution. -> >=20 +> > > > I have not been able to get my hands on the machine yet to do an actual > > bisect, but I'm wondering if you guys might have an idea of what is > > wrong. -> >=20 +> > > > Any help is appreciated :) ->=20 +> > Hi Gabriel, ->=20 +> > This appears to be new behavior in blk-mq's tag set update with commit > 705cda97e. This is asserting a lock is held, but none of the drivers > that call the export are take that lock. ->=20 +> > I think the below should fix it (CC'ing block list and developers). ->=20 +> > --- > diff --git a/block/blk-mq.c b/block/blk-mq.c > index f2224ffd..1bccced 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c -> @@ -2641,7 +2641,8 @@ int blk_mq_update_nr_requests(struct request_queue = -*q, unsigned int nr) +> @@ -2641,7 +2641,8 @@ int blk_mq_update_nr_requests(struct request_queue *q, unsigned int nr) > return ret; > } -> =20 -> -void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_qu= -eues) +> +> -void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues) > +static void __blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, > + int nr_hw_queues) > { > struct request_queue *q; -> =20 -> @@ -2665,6 +2666,13 @@ void blk_mq_update_nr_hw_queues(struct blk_mq_tag_= -set *set, int nr_hw_queues) +> +> @@ -2665,6 +2666,13 @@ void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues) > list_for_each_entry(q, &set->tag_list, tag_set_list) > blk_mq_unfreeze_queue(q); > } > + -> +void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_qu= -eues) +> +void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues) > +{ > + mutex_lock(&set->tag_list_lock); > + __blk_mq_update_nr_hw_queues(set, nr_hw_queues); @@ -61,4 +55,4 @@ eues) These changes look fine to me, hence: -Reviewed-by: Bart Van Assche <Bart.VanAssche@sandisk.com> +Reviewed-by: Bart Van Assche <Bart.VanAssche at sandisk.com> diff --git a/a/content_digest b/N1/content_digest index 89497f4..795c16f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,69 +1,58 @@ "ref\08760giqnyb.fsf@dilma.collabora.co.uk\0" "ref\020170530175549.GC2845@localhost.localdomain\0" - "From\0Bart Van Assche <Bart.VanAssche@sandisk.com>\0" - "Subject\0Re: WARNING triggers at blk_mq_update_nr_hw_queues during nvme_reset_work\0" + "From\0Bart.VanAssche@sandisk.com (Bart Van Assche)\0" + "Subject\0WARNING triggers at blk_mq_update_nr_hw_queues during nvme_reset_work\0" "Date\0Tue, 30 May 2017 18:09:22 +0000\0" - "To\0keith.busch@intel.com <keith.busch@intel.com>" - " krisman@collabora.co.uk <krisman@collabora.co.uk>\0" - "Cc\0linux-nvme@lists.infradead.org <linux-nvme@lists.infradead.org>" - linux-block@vger.kernel.org <linux-block@vger.kernel.org> - " axboe@fb.com <axboe@fb.com>\0" "\00:1\0" "b\0" - "On Tue, 2017-05-30 at 13:55 -0400, Keith Busch wrote:\n" - "> On Tue, May 30, 2017 at 02:00:44PM -0300, Gabriel Krisman Bertazi wrote:\n" + "On Tue, 2017-05-30@13:55 -0400, Keith Busch wrote:\n" + "> On Tue, May 30, 2017@02:00:44PM -0300, Gabriel Krisman Bertazi wrote:\n" "> > Since the merge window for 4.12, one of the machines in Intel's CI\n" - "> > started to hit the WARN_ON below at blk_mq_update_nr_hw_queues during a=\n" - "n\n" + "> > started to hit the WARN_ON below at blk_mq_update_nr_hw_queues during an\n" "> > nvme_reset_work. The issue persists with the latest 4.12-rc3, and full\n" "> > dmesg from boot, up to the moment where the WARN_ON triggers is\n" "> > available at the following link:\n" - "> >=20\n" - "> > https://intel-gfx-ci.01.org/CI/CI_DRM_2672/fi-kbl-7500u/igt@kms_pipe_cr=\n" - "c_basic@suspend-read-crc-pipe-a.html\n" - "> >=20\n" + "> > \n" + "> > https://intel-gfx-ci.01.org/CI/CI_DRM_2672/fi-kbl-7500u/igt at kms_pipe_crc_basic@suspend-read-crc-pipe-a.html\n" + "> > \n" "> > Please notice that the test we do in the CI involves putting the\n" "> > machine to sleep (PM), and the issue triggers when resuming execution.\n" - "> >=20\n" + "> > \n" "> > I have not been able to get my hands on the machine yet to do an actual\n" "> > bisect, but I'm wondering if you guys might have an idea of what is\n" "> > wrong.\n" - "> >=20\n" + "> > \n" "> > Any help is appreciated :)\n" - ">=20\n" + "> \n" "> Hi Gabriel,\n" - ">=20\n" + "> \n" "> This appears to be new behavior in blk-mq's tag set update with commit\n" "> 705cda97e. This is asserting a lock is held, but none of the drivers\n" "> that call the export are take that lock.\n" - ">=20\n" + "> \n" "> I think the below should fix it (CC'ing block list and developers).\n" - ">=20\n" + "> \n" "> ---\n" "> diff --git a/block/blk-mq.c b/block/blk-mq.c\n" "> index f2224ffd..1bccced 100644\n" "> --- a/block/blk-mq.c\n" "> +++ b/block/blk-mq.c\n" - "> @@ -2641,7 +2641,8 @@ int blk_mq_update_nr_requests(struct request_queue =\n" - "*q, unsigned int nr)\n" + "> @@ -2641,7 +2641,8 @@ int blk_mq_update_nr_requests(struct request_queue *q, unsigned int nr)\n" "> \treturn ret;\n" "> }\n" - "> =20\n" - "> -void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_qu=\n" - "eues)\n" + "> \n" + "> -void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues)\n" "> +static void __blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set,\n" "> +\t\t\t\t\t\t\tint nr_hw_queues)\n" "> {\n" "> \tstruct request_queue *q;\n" - "> =20\n" - "> @@ -2665,6 +2666,13 @@ void blk_mq_update_nr_hw_queues(struct blk_mq_tag_=\n" - "set *set, int nr_hw_queues)\n" + "> \n" + "> @@ -2665,6 +2666,13 @@ void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues)\n" "> \tlist_for_each_entry(q, &set->tag_list, tag_set_list)\n" "> \t\tblk_mq_unfreeze_queue(q);\n" "> }\n" "> +\n" - "> +void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_qu=\n" - "eues)\n" + "> +void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues)\n" "> +{\n" "> +\tmutex_lock(&set->tag_list_lock);\n" "> +\t__blk_mq_update_nr_hw_queues(set, nr_hw_queues);\n" @@ -73,6 +62,6 @@ "\n" "These changes look fine to me, hence:\n" "\n" - Reviewed-by: Bart Van Assche <Bart.VanAssche@sandisk.com> + Reviewed-by: Bart Van Assche <Bart.VanAssche at sandisk.com> -21843b9f17828baa0e88e84c74235eb7308afa0cbfa2577f5ee223310919248d +cb52e7954d82b3085a362200c532c5f2859a76797c936c34666c238778595041
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.