On Mon, Mar 4, 2013 at 12:09 PM, Mandeep Singh Baines <m...@chromium.org> wrote: > On Mon, Mar 4, 2013 at 7:53 AM, Myklebust, Trond > <trond.mykleb...@netapp.com> wrote: >> 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 <jlay...@redhat.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 <m...@chromium.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. >> > > Hi Trond, > > My intention was to introduce new rules. My change simply introduces a
D'oh. s/was/was not/ Regards, Mandeep > check for a deadlock case that can already happen. > > I think a deadlock could happen under the following scenario: > > 1) An administrator wants to freeze a container. Perhaps to checkpoint > it and it migrate it some place else. > 2) An nfs mount was in progress so we hit this code path and freeze > with a lock held. > 3) Another container tries to nfs mount. > 4) Deadlock. > > Regards, > Mandeep > >> Trond >> -- >> Trond Myklebust >> Linux NFS client maintainer >> >> NetApp >> trond.mykleb...@netapp.com >> www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
