Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932358Ab3CGQpX (ORCPT ); Thu, 7 Mar 2013 11:45:23 -0500 Received: from mx2.netapp.com ([216.240.18.37]:6471 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755155Ab3CGQpV convert rfc822-to-8bit (ORCPT ); Thu, 7 Mar 2013 11:45:21 -0500 X-IronPort-AV: E=Sophos;i="4.84,803,1355126400"; d="scan'208";a="13755847" From: "Myklebust, Trond" To: Linus Torvalds CC: Jeff Layton , Tejun Heo , Oleg Nesterov , Mandeep Singh Baines , Ming Lei , "J. Bruce Fields" , "Linux Kernel Mailing List" , "linux-nfs@vger.kernel.org" , "Rafael J. Wysocki" , Andrew Morton , Ingo Molnar , Al Viro Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held! Thread-Topic: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held! Thread-Index: AQHOGOA9OOKbapJ+RE+tLJb3WRyEW5iWGYKAgAACcQCAAFy3AIAAED2AgAAVFoCAAP+FAIAASasAgAAA3gCAABR7AIAAAbqAgABLhYCAAAIMAIABNeMAgAAKUgCAACN5AIAABvAAgAABwwCAAAGFAIAA7BsAgABG94CAAAERAIAABy4AgAAFngA= Date: Thu, 7 Mar 2013 16:45:17 +0000 Message-ID: <4FA345DA4F4AE44899BD2B03EEEC2FA9286B52F1@sacexcmbx05-prd.hq.netapp.com> References: <20130305174954.GG12795@htj.dyndns.org> <20130305140312.243cb094@tlielax.poochiereds.net> <20130305190923.GI12795@htj.dyndns.org> <20130305183941.19ff39ce@tlielax.poochiereds.net> <20130305234700.GE1227@htj.dyndns.org> <20130306181608.GA18687@redhat.com> <20130306185304.GM1227@htj.dyndns.org> <20130306212452.GO1227@htj.dyndns.org> <20130306213636.GP1227@htj.dyndns.org> <20130307064140.71c0936b@tlielax.poochiereds.net> <4FA345DA4F4AE44899BD2B03EEEC2FA9286B511E@sacexcmbx05-prd.hq.netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset=US-ASCII Content-ID: Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2098 Lines: 49 On Thu, 2013-03-07 at 08:25 -0800, Linus Torvalds wrote: > On Thu, Mar 7, 2013 at 7:59 AM, Myklebust, Trond > wrote: > > > > It _shouldn't_ be an interruption unless the filesystem can't make > > progress. > > So how can we tell? Calling "freezable_schedule()" if you're not ready > to be frozen is not good. And nobody but the NFS code can know. > > You might want to introduce some counter that counts number of > outstanding non-interruptible events, and only call the "freezable" > version if that counter is zero. > > A better alternative might be to *never* call the freezable version. > Because those freezable_*() things are really quite disgusting, and > are wrong - they don't actually freeze the process, they say "I don't > care if you freeze me while I sleep", and you might actually wake up > *while* the system is being frozen. I think the whole concept is > broken. Rafaei - comments? The function really is crap, regardless of > any unrelated NFS problems. > > So what NFS could do instead is actually check the "do I need to > freeze" flag, and if you need to freeze you consider it an abort - and > do *not* try to continue. Just freeze, and then act as if the machine > got rebooted as far as NFS was concerned. That should work anyway, no? > > That does sound a lot more complex, though. The problem there is that we get into the whole 'hard' vs 'soft' mount problem. We're supposed to guarantee data integrity for 'hard' mounts, so no funny business is allowed. OTOH, 'soft' mounts time out and return EIO to the application anyway, and so shouldn't be a problem. Perhaps we could add a '-oslushy' mount option :-) that guarantees data integrity for all situations _except_ ENETDOWN/ENETUNREACH? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/