Subject: Re: calling flush_scheduled_work()
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Tim Hockin <thockin@Sun.COM>
Cc: Linux Kernel mailing list <linux-kernel@vger.kernel.org>
In-Reply-To: <20040312205814.GY1333@sun.com>
References: <20040312205814.GY1333@sun.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Message-Id: <1079128848.3166.44.camel@lade.trondhjem.org>
Mime-Version: 1.0
Date: Fri, 12 Mar 2004 17:00:48 -0500
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1484
Lines: 33

P? fr , 12/03/2004 klokka 15:58, skreiv Tim Hockin:
> 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.
> 
> So what is the real bug?
> 
> Is it verboten to call mntput() from keventd?  What other things might lead
> to a flush_scheduled_work() and must therefore be avoided?
> 
> Should callers of flush_scheduled_work() be changed to use private
> workqueues?  There are 31 calls that I got from grep.  25 are in drivers/, 1
> in ncpfs, 3 in nfs4, 2 in sunrpc.  The drivers/ are *probably* ok. Should
> those other 6 be changed?

It would be dead easy to change RPC+NFS to use their own, workqueue. In
fact I've already considered that several times in the places where the
NFSv4 state stuff gets hairy. ... but it might be nice not to have to
set up all these (mostly) idle threads for exclusive use by NFS just in
order to catch a corner case.

Could we therefore perhaps consider setting up one or more global
workqueues that would be alternatives to keventd?

Cheers,
  Trond
-
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/