From: Tejun Heo <tj@kernel.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
Oleg Nesterov <oleg@redhat.com>,
Mandeep Singh Baines <msb@chromium.org>,
Ming Lei <ming.lei@canonical.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!
Date: Tue, 5 Mar 2013 09:46:48 -0800 [thread overview]
Message-ID: <20130305174648.GF12795@htj.dyndns.org> (raw)
In-Reply-To: <20130305082308.6607d4db@tlielax.poochiereds.net>
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
next prev parent reply other threads:[~2013-03-05 17:47 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 13:57 LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held! Ming Lei
2013-03-04 14:14 ` Myklebust, Trond
2013-03-04 14:23 ` Jeff Layton
2013-03-04 19:55 ` Mandeep Singh Baines
2013-03-04 20:53 ` Oleg Nesterov
2013-03-04 22:08 ` Myklebust, Trond
2013-03-05 13:23 ` Jeff Layton
2013-03-05 17:46 ` Tejun Heo [this message]
2013-03-05 17:49 ` Tejun Heo
2013-03-05 19:03 ` Jeff Layton
2013-03-05 19:09 ` Tejun Heo
2013-03-05 23:39 ` Jeff Layton
2013-03-05 23:47 ` Tejun Heo
2013-03-06 18:16 ` Oleg Nesterov
2013-03-06 18:53 ` Tejun Heo
2013-03-06 21:00 ` Linus Torvalds
2013-03-06 21:24 ` Tejun Heo
2013-03-06 21:31 ` Linus Torvalds
2013-03-06 21:36 ` Tejun Heo
2013-03-06 21:40 ` Tejun Heo
2013-03-13 15:17 ` Jeff Layton
2013-03-31 0:07 ` Paul Walmsley
2013-03-07 11:41 ` Jeff Layton
2013-03-07 15:25 ` Tejun Heo
2013-03-07 15:55 ` Linus Torvalds
2013-03-07 15:59 ` Myklebust, Trond
2013-03-07 16:25 ` Linus Torvalds
2013-03-07 16:45 ` Myklebust, Trond
2013-03-07 17:03 ` Linus Torvalds
2013-03-07 17:16 ` Myklebust, Trond
2013-03-07 21:43 ` Jeff Layton
2013-03-08 14:01 ` Ingo Molnar
2013-03-07 20:55 ` Rafael J. Wysocki
2013-03-07 16:00 ` Tejun Heo
2013-03-06 18:17 ` Oleg Nesterov
2013-03-06 18:40 ` Jeff Layton
2013-03-06 18:45 ` Tejun Heo
2013-03-06 1:10 ` Myklebust, Trond
2013-03-06 1:14 ` Tejun Heo
2013-03-06 1:28 ` Tejun Heo
2013-03-06 12:00 ` Jeff Layton
2013-03-05 23:11 ` J. Bruce Fields
2013-03-06 0:02 ` Rafael J. Wysocki
2013-03-06 0:30 ` [PATCH] lockdep: make lock held while freezing check optional Mandeep Singh Baines
2013-03-07 12:03 ` Maarten Lankhorst
2013-03-06 0:59 ` LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held! Mandeep Singh Baines
2013-03-06 1:05 ` J. Bruce Fields
2013-03-06 1:16 ` Tejun Heo
2013-03-06 3:11 ` Mandeep Singh Baines
2013-03-06 9:09 ` Ingo Molnar
2013-03-06 12:06 ` Jeff Layton
2013-03-06 15:59 ` Mandeep Singh Baines
2013-03-06 18:23 ` Jeff Layton
2013-03-06 18:37 ` Myklebust, Trond
2013-03-06 20:15 ` Mandeep Singh Baines
2013-03-04 14:40 ` Ming Lei
2013-03-04 15:04 ` Jeff Layton
2013-03-04 15:33 ` Ming Lei
2013-03-04 15:53 ` Myklebust, Trond
2013-03-04 20:09 ` Mandeep Singh Baines
2013-03-04 20:10 ` Mandeep Singh Baines
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130305174648.GF12795@htj.dyndns.org \
--to=tj@kernel.org \
--cc=Trond.Myklebust@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=mingo@redhat.com \
--cc=msb@chromium.org \
--cc=oleg@redhat.com \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).