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

[Myklebust, Trond]

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@xxxxxxxxxx> 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@xxxxxxxxxxxx>
> 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@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/