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: <4FA345DA4F4AE44899BD2B03EEEC2FA9286AEEB0@sacexcmbx05-prd.hq.netapp.com>
Date:	Mon, 4 Mar 2013 22:08:34 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	Mandeep Singh Baines <msb@...omium.org>,
	Jeff Layton <jlayton@...hat.com>,
	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>,
	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...hat.com>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

On Mon, 2013-03-04 at 21:53 +0100, Oleg Nesterov wrote:
> On 03/04, Mandeep Singh Baines wrote:
> >
> > The problem is that freezer_count() calls try_to_freeze(). In this
> > case, try_to_freeze() is not really adding any value.
> 
> Well, I tend to agree.
> 
> If a task calls __refrigerator() holding a lock which another freezable
> task can wait for, this is not freezer-friendly.
> 
> freezable_schedule/freezer_do_not_count/etc not only means "I won't be
> active if freezing()", it should also mean "I won't block suspend/etc".

If suspend for some reason requires a re-entrant mount, then yes, I can
see how it might be a problem that we're holding a mount-related lock.
The question is why is that necessary?

> OTOH, I understand that probably it is not trivial to change this code
> to make it freezer-friendly. But at least  I disagree with "push your
> problems onto others".

That code can't be made freezer-friendly if it isn't allowed to hold
basic filesystem-related locks across RPC calls. A number of those RPC
calls do things that need to be protected by VFS or MM-level locks.
i.e.: lookups, file creation/deletion, page fault in/out, ...

IOW: the problem would need to be solved differently, possibly by adding
a new FIFREEZE-like call to allow the filesystem to quiesce itself
_before_ NetworkManager pulls the rug out from underneath it. There
would still be plenty of corner cases to keep people entertained (e.g.
the server goes down before the quiesce call is invoked) but at least
the top 90% of cases would be solved.

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