From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Harkes Subject: Re: [PATCH 2.4.19pre8][RFC] remove-NFS-close-to-open from VFS (was Re: [PATCHSET] 2.4.19-pre8-jp12) Date: Fri, 18 Oct 2002 12:49:16 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20021018164916.GA11336@ravel.coda.cs.cmu.edu> References: <200205162142.AWF00051@netmail.netcologne.de> <20020517034357.GA18449@ravel.coda.cs.cmu.edu> <20021017203804.GA24523@ravel.coda.cs.cmu.edu> <15791.12331.663212.692225@charged.uio.no> <20021017221652.GA26692@ravel.coda.cs.cmu.edu> <15791.20061.369962.893823@charged.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: To: Trond Myklebust Content-Disposition: inline In-Reply-To: <15791.20061.369962.893823@charged.uio.no> List-Id: linux-fsdevel.vger.kernel.org On Fri, Oct 18, 2002 at 01:57:17AM +0200, Trond Myklebust wrote: > Client Server > ------ -------- > cd foo > mv foo bar > open(".") > > You are basically saying that you believe that the above scenario must > always fail and that the VFS should enforce a violation of POSIX > rules. The current code has the possibility to recover from the above > sort of thing: this will not be the case if you have to look up 'foo' > on the server in order to do open(".") I must be blind, because nfs_lookup_revalidate does, dir = dentry->d_parent->d_inode; ... error = NFS_PROTO(dir)->lookup(dir, &dentry->d_name, &fhandle, &fattr); if (error) goto out_bad; So how is this recovering any better from the scenario you just gave? > So? That's just because those lines usually lie just after a > cached_lookup(), which bumps the count. Read the code in question: it > is not leaking dentries. Ah, got confused by the dput in the out_dput path, must have missed the return 0; right above it. Jan