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]

Date:	Mon, 4 Mar 2013 15:53:33 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Ming Lei <ming.lei@...onical.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>
CC:	Jeff Layton <jlayton@...hat.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>,
	Mandeep Singh Baines <msb@...omium.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Ben Chan <benchan@...omium.org>,
	"Oleg Nesterov" <oleg@...hat.com>, Ingo Molnar <mingo@...hat.com>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

On Mon, 2013-03-04 at 23:33 +0800, Ming Lei wrote:
> Hi,
> 
> CC guys who introduced the lockdep change.
> 
> On Mon, Mar 4, 2013 at 11:04 PM, Jeff Layton <jlayton@...hat.com> wrote:
> 
> >
> > I don't get it -- why is it bad to hold a lock across a freeze event?
> 
> At least this may deadlock another mount.nfs during freezing, :-)
> 
> See detailed explanation in the commit log:
> 
> commit 6aa9707099c4b25700940eb3d016f16c4434360d
> Author: Mandeep Singh Baines <msb@...omium.org>
> Date:   Wed Feb 27 17:03:18 2013 -0800
> 
>     lockdep: check that no locks held at freeze time
> 
>     We shouldn't try_to_freeze if locks are held.  Holding a lock can cause a
>     deadlock if the lock is later acquired in the suspend or hibernate path
>     (e.g.  by dpm).  Holding a lock can also cause a deadlock in the case of
>     cgroup_freezer if a lock is held inside a frozen cgroup that is later
>     acquired by a process outside that group.
> 

This is bloody ridiculous... If you want to add functionality to
implement cgroup or per-process freezing, then do it through some other
api instead of trying to push your problems onto others by adding new
global locking rules.

Filesystems are a shared resource that have _nothing_ to do with process
cgroups. They need to be suspended when the network goes down or other
resources that they depend on are suspended. At that point, there is no
"what if I launch a new mount command?" scenario.

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