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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 7 Mar 2013 15:59:27 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Jeff Layton <jlayton@...hat.com>, Tejun Heo <tj@...nel.org>,
	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>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

On Thu, 2013-03-07 at 07:55 -0800, Linus Torvalds wrote:
> On Thu, Mar 7, 2013 at 3:41 AM, Jeff Layton <jlayton@...hat.com> wrote:
> >
> > I think Trond may be on the right track. We probably need some
> > mechanism to quiesce the filesystem ahead of any sort of freezer
> > event.
> 
> No, guys. That cannot work. It's a completely moronic idea. Let me
> count the way:
> 
>  (a) it's just another form of saying "lock". But since other things
> are (by definition) going on when it happens, it will just cause
> deadlocks.
> 
>  (b) the freeze event might not even be system-global. So *some*
> processes (a cgroup) might freeze, others would not. You can't shut
> off the filesystem just because some processes migth freeze.

That's the whole bloody problem in a nutshell.

We only want to freeze the filesystem when the network goes down, and in
that case we want time to clean up first. That's why it needs to be
initiated by something like NetworkManager _before_ the network is shut
down.

>  (c) it just moves the same issue somewhere else. If you have some
> operation that must be done under the lock, then such an operation
> must be completed before you've quiesced the filesystem, which is your
> whole point of that "quiesce" event. BUT THAT'S THE EXACT SAME ISSUE
> AS NOT ALLOWING THE FREEZE TO HAPPEN DURING THAT TIME.
> 
> In other words, that suggestion not only introduces new problems (a),
> it's fundamentally broken anyway (b) *AND* it doesn't even solve
> anything, it just moves it around.
> 
> The solution is damn simple: if you're in some kind of "atomic
> region", then you cannot freeze. Seriously. SO DON'T CALL
> "freezable_schedule()", FOR CHRISSAKE! You clearly aren't freezable!
> 
> Which is exactly what the new lockdep warning was all about. Don't try
> to move the problem around, when it's quite clear where the problem
> is. If you need to do something uninterruptible, you do not say "oh,
> I'm freezable". Because freezing is by definition an interruption.
> Seriously, it's that simple.

It _shouldn't_ be an interruption unless the filesystem can't make
progress.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
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/