From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [Ocfs2-devel] [RFC PATCH] ocfs2: don't depend on DCACHE_DISCONNECTED Date: Thu, 16 Aug 2012 15:42:03 -0400 Message-ID: <20120816194203.GC4385@fieldses.org> References: <20120731223323.GA32253@fieldses.org> <20120802075743.GA3368@dhcp-172-17-9-228.mtv.corp.google.com> <20120802125910.GC9849@fieldses.org> <20120815102241.GP31083@dhcp-172-17-9-228.mtv.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Mark Fasheh , ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org Return-path: Received: from fieldses.org ([174.143.236.118]:51839 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757621Ab2HPTmH (ORCPT ); Thu, 16 Aug 2012 15:42:07 -0400 Content-Disposition: inline In-Reply-To: <20120815102241.GP31083@dhcp-172-17-9-228.mtv.corp.google.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Aug 15, 2012 at 03:22:42AM -0700, Joel Becker wrote: > So, I think you are right that we can't be relying on it *that* > much, because splicing the alias doesn't clear it right away. In other > words, we rely on other mechanisms to ensure we have our lock attached > when the dentry is reachable, but if we're dropping an unreachable > dentry, we might not have the lock attached, and we need to detect that. > So your original point, that the code "can't be right", is > really that the code is overly permissive. If we have a reachable tree > with DISCONNECTED not yet cleared, that lock should be attached, but > this check won't catch it. That's fine. We rely on other code. > Conversely, we *know* we can get here with DISCONNECTED set from nfs or > d_kill, and we don't want to print errors for a sane state. OK, so we're depending on the DCACHE_DISCONNECTED check *only* to decide whether to warn, and you don't mind missing some warnings as long as you never warn when you shouldn't. Makes sense, thanks! --b.