Date: Fri, 12 Mar 2004 15:27:47 -0800
From: Andrew Morton <akpm@osdl.org>
To: thockin@sun.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: calling flush_scheduled_work()
Message-Id: <20040312152747.0b3f74d3.akpm@osdl.org>
In-Reply-To: <20040312205814.GY1333@sun.com>
References: <20040312205814.GY1333@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1382
Lines: 43

Tim Hockin <thockin@sun.com> wrote:
>
> We've recently bumped into an issue, and I'm not sure which is the real bug.
> 
> In short we have a case where mntput() is called from the kevetd workqueue.
> When that mntput() hit an NFS mount, we got a deadlock.  It turns out that
> deep in the RPC code, someone calls flush_scheduled_work().  Deadlock.

Seems simple enough to fix the workqueue code to handle this situation.

Wanna test this for me?

---

 25-akpm/kernel/workqueue.c |    8 ++++++++
 1 files changed, 8 insertions(+)

diff -puN kernel/workqueue.c~flush_scheduled_work-deadlock-fix kernel/workqueue.c
--- 25/kernel/workqueue.c~flush_scheduled_work-deadlock-fix	Fri Mar 12 15:24:29 2004
+++ 25-akpm/kernel/workqueue.c	Fri Mar 12 15:25:46 2004
@@ -229,6 +229,14 @@ void fastcall flush_workqueue(struct wor
 			continue;
 		cwq = wq->cpu_wq + cpu;
 
+		if (cwq->thread == current) {
+			/*
+			 * Probably keventd trying to flush its own queue.
+			 * So just run it by hand rather than deadlocking
+			 */
+			run_workqueue(cwq);
+			continue;
+		}
 		spin_lock_irq(&cwq->lock);
 		sequence_needed = cwq->insert_sequence;
 

_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/