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]
Date:	Thu, 7 Mar 2013 07:55:39 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...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!

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.

 (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.

                Linus
--
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