linux-kernel - Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130306185304.GM1227@htj.dyndns.org>
Date:	Wed, 6 Mar 2013 10:53:04 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	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, Oleg.

On Wed, Mar 06, 2013 at 07:16:08PM +0100, Oleg Nesterov wrote:
> And how SIGFREEZE can help? If we want to interrupt the sleeps in NFS/RPC
> layer we can simply add TASK_WAKEFREEZE (can be used with TASK_KILLABLE)
> and change freeze_task() to do signal_wake_up_state(TASK_WAKEFREEZE).

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.

> But if we can do this, then it should be possible so simply make these
> sleeps TASK_INTERRUPTIBLE ? But it seems that we can't just because we
> can't always restart, so I am totally confused.

Of course, switching to another freezing mechanism doesn't make issues
like this go away in itself, but it would at least allow handling such
issues in easier to grasp way rather than dealing with this giant
pseudo lock and allows code paths outside jobctl to simply deal with
one issue - signal delivery, rather than having to deal with freezing
separately.  Also, while not completely identical, frozen state would
at least be an extension of jobctl trap and it would be possible to
allow things like killing frozen tasks or even ptracing them in
well-defined manner for cgroup_freezer use cases.  As it currently
stands, there is no well-defined abstraction for frozen state which we
can expose in any way, which sucks.

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/