[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130305174648.GF12795@htj.dyndns.org>
Date: Tue, 5 Mar 2013 09:46:48 -0800
From: Tejun Heo <tj@...nel.org>
To: Jeff Layton <jlayton@...hat.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@...app.com>,
Oleg Nesterov <oleg@...hat.com>,
Mandeep Singh Baines <msb@...omium.org>,
Ming Lei <ming.lei@...onical.com>,
"J. Bruce Fields" <bfields@...ldses.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!
Hello, guys.
On Tue, Mar 05, 2013 at 08:23:08AM -0500, Jeff Layton wrote:
> So, not a deadlock per-se in this case but it does prevent the freezer
> from running to completion. I don't see any way to solve it though w/o
> making all mutexes freezable. Note that I don't think this is really
> limited to NFS either -- a lot of other filesystems will have similar
> problems: CIFS, some FUSE variants, etc...
So, I think this is why implementing freezer as a separate blocking
mechanism isn't such a good idea. We're effectively introducing a
completely new waiting state to a lot of unsuspecting paths which
generates a lot of risks and eventually extra complexity to work
around those. I think we really should update freezer to re-use the
blocking points we already have - the ones used for signal delivery
and ptracing. That way, other code paths don't have to worry about an
extra stop state and we can confine most complexities to freezer
proper.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists