diff for duplicates of <MWHPR03MB26699D4657FB67A535972208BF430@MWHPR03MB2669.namprd03.prod.outlook.com>
diff --git a/a/1.txt b/N1/1.txt
index 46ffc0c..6441839 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,20 +3,17 @@
> Sent: Friday, February 3, 2017 20:23
> To: Hannes Reinecke <hare@suse.com>; Bart Van Assche
> <Bart.VanAssche@sandisk.com>; hare@suse.de; axboe@kernel.dk
-> Cc: hch@lst.de; linux-kernel@vger.kernel.org; linux-block@vger.kernel.org=
-;
+> Cc: hch@lst.de; linux-kernel@vger.kernel.org; linux-block@vger.kernel.org;
> jth@kernel.org
-> Subject: RE: [PATCH] genhd: Do not hold event lock when scheduling workqu=
-eue
+> Subject: RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue
> elements
->=20
+>
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@vger.kernel.org] On Behalf Of Hannes Reinecke
> > Sent: Wednesday, February 1, 2017 00:15
> > To: Bart Van Assche <Bart.VanAssche@sandisk.com>; hare@suse.de;
> > axboe@kernel.dk
-> > Cc: hch@lst.de; linux-kernel@vger.kernel.org; linux-block@vger.kernel.o=
-rg;
+> > Cc: hch@lst.de; linux-kernel@vger.kernel.org; linux-block@vger.kernel.org;
> > jth@kernel.org
> > Subject: Re: [PATCH] genhd: Do not hold event lock when scheduling
> workqueue
@@ -28,7 +25,7 @@ rg;
> > disk_events_poll_jiffies(struct gendisk *disk)
> > >> void disk_block_events(struct gendisk *disk)
> > >> {
-> > >> struct disk_events *ev =3D disk->ev;
+> > >> struct disk_events *ev = disk->ev;
> > >> - unsigned long flags;
> > >> - bool cancel;
> > >>
@@ -36,19 +33,17 @@ rg;
> > >> return;
> > >>
> > >> - /*
-> > >> - * Outer mutex ensures that the first blocker completes canc=
-eling
-> > >> - * the event work before further blockers are allowed to fin=
-ish.
+> > >> - * Outer mutex ensures that the first blocker completes canceling
+> > >> - * the event work before further blockers are allowed to finish.
> > >> - */
> > >> - mutex_lock(&ev->block_mutex);
> > >> -
> > >> - spin_lock_irqsave(&ev->lock, flags);
-> > >> - cancel =3D !ev->block++;
+> > >> - cancel = !ev->block++;
> > >> - spin_unlock_irqrestore(&ev->lock, flags);
> > >> -
> > >> - if (cancel)
-> > >> + if (atomic_inc_return(&ev->block) =3D=3D 1)
+> > >> + if (atomic_inc_return(&ev->block) == 1)
> > >> cancel_delayed_work_sync(&disk->ev->dwork);
> > >>
> > >> - mutex_unlock(&ev->block_mutex);
@@ -56,20 +51,14 @@ ish.
> > >
> > > Hello Hannes,
> > >
-> > > I have already encountered a few times a deadlock that was caused by =
-the
-> > > event checking code so I agree with you that it would be a big step f=
-orward
-> > > if such deadlocks wouldn't occur anymore. However, this patch realize=
-s a
-> > > change that has not been described in the patch description, namely t=
-hat
-> > > disk_block_events() calls are no longer serialized. Are you sure it i=
-s safe
+> > > I have already encountered a few times a deadlock that was caused by the
+> > > event checking code so I agree with you that it would be a big step forward
+> > > if such deadlocks wouldn't occur anymore. However, this patch realizes a
+> > > change that has not been described in the patch description, namely that
+> > > disk_block_events() calls are no longer serialized. Are you sure it is safe
> > > to drop the serialization of disk_block_events() calls?
> > >
-> > Well, this whole synchronization stuff it a bit weird; I so totally fai=
-l
+> > Well, this whole synchronization stuff it a bit weird; I so totally fail
> > to see the rationale for it.
> > But anyway, once we've converted ev->block to atomics I _think_ the
> > mutex_lock can remain; will be checking.
@@ -78,17 +67,16 @@ l
> >
> > Hannes
> > --
->=20
-> Hi, I think I got the same calltrace with today's linux-next (next-201702=
-03).
->=20
+>
+> Hi, I think I got the same calltrace with today's linux-next (next-20170203).
+>
> The issue happened every time when my Linux virtual machine booted and
> Hannes's patch could NOT help.
->=20
+>
> The calltrace is pasted below.
->=20
+>
> -- Dexuan
-=20
+
Any news on this thread?
The issue is still blocking Linux from booting up normally in my test. :-(
diff --git a/a/content_digest b/N1/content_digest
index d83e565..be7433c 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -43,20 +43,17 @@
"> Sent: Friday, February 3, 2017 20:23\n",
"> To: Hannes Reinecke <hare\@suse.com>; Bart Van Assche\n",
"> <Bart.VanAssche\@sandisk.com>; hare\@suse.de; axboe\@kernel.dk\n",
- "> Cc: hch\@lst.de; linux-kernel\@vger.kernel.org; linux-block\@vger.kernel.org=\n",
- ";\n",
+ "> Cc: hch\@lst.de; linux-kernel\@vger.kernel.org; linux-block\@vger.kernel.org;\n",
"> jth\@kernel.org\n",
- "> Subject: RE: [PATCH] genhd: Do not hold event lock when scheduling workqu=\n",
- "eue\n",
+ "> Subject: RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue\n",
"> elements\n",
- ">=20\n",
+ "> \n",
"> > From: linux-kernel-owner\@vger.kernel.org [mailto:linux-kernel-\n",
"> > owner\@vger.kernel.org] On Behalf Of Hannes Reinecke\n",
"> > Sent: Wednesday, February 1, 2017 00:15\n",
"> > To: Bart Van Assche <Bart.VanAssche\@sandisk.com>; hare\@suse.de;\n",
"> > axboe\@kernel.dk\n",
- "> > Cc: hch\@lst.de; linux-kernel\@vger.kernel.org; linux-block\@vger.kernel.o=\n",
- "rg;\n",
+ "> > Cc: hch\@lst.de; linux-kernel\@vger.kernel.org; linux-block\@vger.kernel.org;\n",
"> > jth\@kernel.org\n",
"> > Subject: Re: [PATCH] genhd: Do not hold event lock when scheduling\n",
"> workqueue\n",
@@ -68,7 +65,7 @@
"> > disk_events_poll_jiffies(struct gendisk *disk)\n",
"> > >> void disk_block_events(struct gendisk *disk)\n",
"> > >> {\n",
- "> > >> struct disk_events *ev =3D disk->ev;\n",
+ "> > >> struct disk_events *ev = disk->ev;\n",
"> > >> - unsigned long flags;\n",
"> > >> - bool cancel;\n",
"> > >>\n",
@@ -76,19 +73,17 @@
"> > >> return;\n",
"> > >>\n",
"> > >> - /*\n",
- "> > >> - * Outer mutex ensures that the first blocker completes canc=\n",
- "eling\n",
- "> > >> - * the event work before further blockers are allowed to fin=\n",
- "ish.\n",
+ "> > >> - * Outer mutex ensures that the first blocker completes canceling\n",
+ "> > >> - * the event work before further blockers are allowed to finish.\n",
"> > >> - */\n",
"> > >> - mutex_lock(&ev->block_mutex);\n",
"> > >> -\n",
"> > >> - spin_lock_irqsave(&ev->lock, flags);\n",
- "> > >> - cancel =3D !ev->block++;\n",
+ "> > >> - cancel = !ev->block++;\n",
"> > >> - spin_unlock_irqrestore(&ev->lock, flags);\n",
"> > >> -\n",
"> > >> - if (cancel)\n",
- "> > >> + if (atomic_inc_return(&ev->block) =3D=3D 1)\n",
+ "> > >> + if (atomic_inc_return(&ev->block) == 1)\n",
"> > >> cancel_delayed_work_sync(&disk->ev->dwork);\n",
"> > >>\n",
"> > >> - mutex_unlock(&ev->block_mutex);\n",
@@ -96,20 +91,14 @@
"> > >\n",
"> > > Hello Hannes,\n",
"> > >\n",
- "> > > I have already encountered a few times a deadlock that was caused by =\n",
- "the\n",
- "> > > event checking code so I agree with you that it would be a big step f=\n",
- "orward\n",
- "> > > if such deadlocks wouldn't occur anymore. However, this patch realize=\n",
- "s a\n",
- "> > > change that has not been described in the patch description, namely t=\n",
- "hat\n",
- "> > > disk_block_events() calls are no longer serialized. Are you sure it i=\n",
- "s safe\n",
+ "> > > I have already encountered a few times a deadlock that was caused by the\n",
+ "> > > event checking code so I agree with you that it would be a big step forward\n",
+ "> > > if such deadlocks wouldn't occur anymore. However, this patch realizes a\n",
+ "> > > change that has not been described in the patch description, namely that\n",
+ "> > > disk_block_events() calls are no longer serialized. Are you sure it is safe\n",
"> > > to drop the serialization of disk_block_events() calls?\n",
"> > >\n",
- "> > Well, this whole synchronization stuff it a bit weird; I so totally fai=\n",
- "l\n",
+ "> > Well, this whole synchronization stuff it a bit weird; I so totally fail\n",
"> > to see the rationale for it.\n",
"> > But anyway, once we've converted ev->block to atomics I _think_ the\n",
"> > mutex_lock can remain; will be checking.\n",
@@ -118,17 +107,16 @@
"> >\n",
"> > Hannes\n",
"> > --\n",
- ">=20\n",
- "> Hi, I think I got the same calltrace with today's linux-next (next-201702=\n",
- "03).\n",
- ">=20\n",
+ "> \n",
+ "> Hi, I think I got the same calltrace with today's linux-next (next-20170203).\n",
+ "> \n",
"> The issue happened every time when my Linux virtual machine booted and\n",
"> Hannes's patch could NOT help.\n",
- ">=20\n",
+ "> \n",
"> The calltrace is pasted below.\n",
- ">=20\n",
+ "> \n",
"> -- Dexuan\n",
- "=20\n",
+ " \n",
"Any news on this thread?\n",
"\n",
"The issue is still blocking Linux from booting up normally in my test. :-(\n",
@@ -140,4 +128,4 @@
"-- Dexuan"
]
-9f7eea0737728f189956bee8f28b163b18cce1008113b3914a45217a303f4e23
+97aa9fe688766466db0b948904c3d1a20335b01bf17677d5ea872314eb8e2311
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.