Date:	Wed, 6 Mar 2013 13:24:52 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, Jeff Layton <jlayton@...hat.com>,
	"Myklebust, Trond" <Trond.Myklebust@...app.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>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

Hello, Linus.

On Wed, Mar 06, 2013 at 01:00:02PM -0800, Linus Torvalds wrote:
> > Oh yeah, we don't need another signal.  We just need sigpending state
> > and a wakeup.  I wasn't really going into details.  The important
> > point is that for code paths outside signal/ptrace, freezing could
> > look and behave about the same as signal delivery.
> 
> Don't we already do that? The whole "try_to_freeze()" in
> get_signal_to_deliver() is about exactly this. See
> fake_signal_wake_up().

Yeap, that was what I had in mind too.  Maybe we'll need to modify it
slightly but we already have most of the basic stuff.

> You still have kernel threads (that don't do signals) to worry about,
> so it doesn't make things go away. And you still have issues with
> latency of disk wait, which is, I think, the reason for that
> "freezable_schedule()" in the NFS code to begin with.

I haven't thought about it for quite some time so things are hazy, but
here's what I can recall now.

With syscall paths out of the way, the surface is reduced a lot.
Another part is converting most freezable kthread users to freezable
workqueue which provides natural resource boundaries (the duration of
work item execution).  kthread is already difficult to get the
synchronization completely right and significant number of freezable +
should_stop users are subtly broken the last time I went over the
freezer users.  I think we would be much better off converting most
over to freezable workqueues which is easier to get right and likely
to be less expensive.  Freezing happens at work item boundary which in
most cases could be made to coincide with the original freezer check
point.

There could be kthreads which can't be converted to workqueue for
whatever reason (there shouldn't be many at this point) but most
freezer usages in kthreads are pretty simple.  It's usually single or
a couple freezer check points in the main loop.  While we may still
need special handling for them, I don't think they're likely to have
implications on issues like this.

We probably would want to handle restart for freezable kthreads
calling syscalls.  Haven't thought about this one too much yet.  Maybe
freezable kthreads doing syscalls just need to be ready for
-ERESTARTSYS?

I'm not sure I follow the disk wait latency part.  Are you saying that
switching to jobctl trap based freezer implementation wouldn't help
them?  If so, right, it doesn't in itself.  It's just changing the
infrastructure used for freezing and can't make the underlying
synchronization issues just disappear but at least it becomes the same
problem as being responsive to SIGKILL rather than a completely
separate problem.

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