Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-ee0-f42.google.com ([74.125.83.42]:45219 "EHLO mail-ee0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753927Ab3CFJJT (ORCPT ); Wed, 6 Mar 2013 04:09:19 -0500 Date: Wed, 6 Mar 2013 10:09:14 +0100 From: Ingo Molnar To: Mandeep Singh Baines Cc: Tejun Heo , "J. Bruce Fields" , Jeff Layton , "Myklebust, Trond" , Oleg Nesterov , Ming Lei , Linux Kernel Mailing List , "linux-nfs@vger.kernel.org" , "Rafael J. Wysocki" , Andrew Morton , Linus Torvalds , Peter Zijlstra , Thomas Gleixner Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held! Message-ID: <20130306090914.GA6030@gmail.com> References: <20130304205307.GA13527@redhat.com> <4FA345DA4F4AE44899BD2B03EEEC2FA9286AEEB0@sacexcmbx05-prd.hq.netapp.com> <20130305082308.6607d4db@tlielax.poochiereds.net> <20130305174648.GF12795@htj.dyndns.org> <20130305174954.GG12795@htj.dyndns.org> <20130305231110.GK15816@fieldses.org> <20130306010507.GL15816@fieldses.org> <20130306011623.GG1227@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: * Mandeep Singh Baines wrote: > On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote: > > On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote: > >> If it's really just a 2-line patch to try_to_freeze(), could it just be > >> carried out-of-tree by people that are specifically working on tracking > >> down these problems? > >> > >> But I don't have strong feelings about it--as long as it doesn't result > >> in the same known issues getting reported again and again.... > > > > Agreed, I don't think a Kconfig option is justified for this. If this > > is really important, annotate broken paths so that it doesn't trigger > > spuriously; otherwise, please just remove it. > > > > Fair enough. Let's revert then. I'll rework to use a lockdep annotation. > > Maybe, add a new lockdep API: > > lockdep_set_held_during_freeze(lock); > > Then when we do the check, ignore any locks that set this bit. > > Ingo, does this seem like a reasonable design to you? Am I reading the discussion correctly that the new warnings show REAL potential deadlock scenarios, which can hit real users and can lock their box up in entirely real usage scenarios? If yes then guys we _really_ don't want to use lockdep annotation to _HIDE_ bugs. We typically use them to teach lockdep about things it does not know about. How about fixing the deadlocks instead? Thanks, Ingo