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-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
